Dplyr: postgresqlschema.tableをdplyrパッケージに接続できません

@hadleyがあなたの答えを考えて私は完全なSQL文を書くために思いついた

my_tbl = tbl（my_db、dplyr :: sql（ 'SELECT * FROM mortalidad.def0307'））

そこで、スキーマとテーブルに接続できました。 どうもありがとう。 –ディエゴ

Greenplumで作業しているときに、これと同じ問題を投稿するつもりでした。 あなたのSQLメソッドは私の問題を解決しました。

私はそれに満足しています。 私が心配しているのは、SQLステートメントで次のことが観察されていることだけです。

SELECT "var1"、count（*）AS "n" FROM（SELECT * FROM mortalidad.mort12）

グループ化が行われたとき。 FROMの後にサブクエリがあり、これがSQLクエリの効率に何らかの問題があるかどうかはわかりません。 私は疫学者ですが、これに気づいていません。

postgresqlで実行してスキーマとそのスキーマにデータベースを作成できる一連のSQLコマンドを教えていただけませんか。

ここで遅れてすみません、私はスキームを作成するために送ります

CREATE TABLE schema_name.table_name
（（
コディゴ文字変化（3）、
nombre文字の変化（51）、
大陸の文字が変化する（7）
）。

2014-03-19 18:56 GMT-03：00ハドリーウィッカム[email protected] ：

実行できるSQLコマンドのシーケンスを教えていただけませんか
postgresqlを使用して、スキーマとそのスキーマにデータベースを作成しますか？

このメールに直接返信するか、Gi tHubhttps：//github.com/hadley/dplyr/issues/244#issuecomment-38112148で表示してください
。

ディエゴガルシラゾ
メディコ
Departamento Programas de Salud
Instituto Nacional de Enfermedades Respiratorias
Av。 ブラスパレラ8260 //サンタフェ//アルゼンチン// 0342-4896850
http://www.anlis.gov.ar/inst/iner/

ここには基本的に2つのオプションがあると思います。

1. 識別子にドットがある場合は常にエスケープする特殊なケース。 これは、 x.yが"x"."y"エスケープされることを意味します。 これには非常に簡潔であるという利点があり、RからSQLに変換されたテーブルがフィールド名に.を使用できないという欠点があります（おそらくあまり一般的ではありません）。
2. 新しいエスケープメカニズムを使用します。 おそらくこれを行う最も簡単な方法は、 ident()を拡張して複数の引数を取ることです（例： ident("x", "y") 。 あるいは、 dot()を定義して、NSEを実行してdot(x, y)を記述できるようにすることもできます。 これはより多くのタイピングですが、既存のコードを壊さないことが保証されています。

これは、テーブル名（例： schema.table ）と、場合によっては結合のフィールド名を明確にするため（例： table.field ）の両方で重要です。

エスケープの動作をグローバルに変更するのは危険だと思われるため、現在、明示的なdot()関数に傾倒しています。

うーん、このユースケースでは、次のことができます。

my_tbl <- tbl(my_db, sql('mortalidad.def0307'))

そして、将来の参照のための他のいくつかのコード（成功しませんでした）

dot <- function(...) {
  args <- dots(...)
  is_name <- vapply(args, is.name, logical(1))
  if (any(!is_name)) {
    stop("All arguments to dot() must be names.")
  }

  dots <- vapply(args, as.character, character(1))
  class(dots) <- c("ident_multi", "ident", "sql", "character")
  dots
}

dot <- function(...) {
  out <- paste(escape(c(...), parens = FALSE), collapse = ".")
  class(out) <- c("ident", "sql", "character")
  out
}

#' <strong i="6">@export</strong>
escape.ident_multi <- function(x, parens = FALSE, collapse = ", ", con = NULL) {
  y <- vapply(x, escape_ident, FUN.VALUE = character(1), con = con)
  paste(y, collapse = ".")
}

#' <strong i="7">@export</strong>
format.ident_multi <- function(x, ...) paste0("<SQL> ", paste(x, collapse = "."))

# lahman_sqlite() %>% tbl("Batting")
# lahman_sqlite() %>% tbl("main.Batting")
# lahman_sqlite() %>% tbl(sql("main.Batting"))
# lahman_sqlite() %>% tbl(dot("main", "Batting"))

こんにちはハドリー、

私は同じ問題を抱えており、ネストはパフォーマンスの問題のようです（私の場合、1億行のデータを処理しているため、深刻な問題です）。 最後の試行が失敗した理由を詳しく説明していただけますか？

ありがとう

FWIW、いくつかのユースケースでは、役立つイディオムは次のとおりです。

dbSendQuery(con$con, build_sql("SET search_path TO ", schema_name))

次に、その接続を使用する後続のクエリは、そのスキーマ内にあります。

こんにちはハーラン、

おかげで-そして私はすでにそのようなものを使用しています（スキーマによって検索パスを拡張していることを除いて。しかしそれは今のところ役立つだけです。2つのスキーマに同じ名前のテーブルがある場合はそうではありません。

とにかく、base_scalarSQLトランスレータで「$」記号をオーバーロードしないのはなぜだろうと思っていました。

rの観点からも意味があります

a $ b $ cの場合、環境（つまり、スキーマ）、baテーブル、およびca列があります。 その場合に修正する必要がある唯一の考えはtbl_sqlであり、table_nameがデータベースに存在するかどうかをこのように単純な方法でチェックするべきではありません。 代わりに、「SELECT」ステートメントがSQLクエリの一部であるかどうかを確認し、含まれていない場合は、前にSELECT *を追加して、この方法で変数を確認します。

この場合、tbl関数に対してNSEを有効にすることもできますか？

そうそう、もう1つコメント：

dbSendQuery

多くの場合、RJDBCでは機能しません（少なくともverticaでは）。 上記のクエリ、つまりSET search_path TO..。

結果を返しません。 dbSendQueryは1つを期待します。 verticaの場合、これは機能せず、dbSendUpdateを使用する必要があります。 それはMySQLにも当てはまりますか（または少なくともdbSendUpdateはMySQLで失敗しません）？

$をオーバーロードするというアイデアが好きです。 次にdplyrに取り組んでいるときに、間違いなくそれについて考えます。

@hhoeflin verticaとの通信にRJDBCではなくRPostgreSQLを試しましたか？

いいえ-RPostgreSQLがオプションであることを知りませんでした。 いずれにせよ、verticaバックエンドはすでにRJDBCに実装されています。 しかし、試してみたところ、データベースに存在するテーブルを見つけるためにアクセスしようとしているpostgresテーブルが異なっているように見えるため、問題が発生しました。

これはDBIを通じて徐々に解決されています： //github.com/rstats-db/DBI/issues/24