Dplyr: Não consigo conectar o schema.table postgresql com o pacote dplyr

@hadley pensando em sua resposta, eu vim para escrever a frase SQL completa

my_tbl = tbl (my_db, dplyr :: sql ('SELECT * FROM mortalidad.def0307'))

e lá eu poderia conectar ao esquema e tabela. Muito obrigado. - diego

Eu ia postar esse mesmo problema ao trabalhar com a Greenplum. Seu método sql resolveu meu problema.

Estou feliz com isso. A única coisa que me preocupa é que na instrução sql o seguinte é observado

SELECT "var1", contagem (*) AS "n" FROM (SELECT * FROM mortalidad.mort12)

quando qualquer agrupamento é feito. Existe uma subconsulta depois de FROM e não sei se isso vai ter algum tipo de problema com a eficiência da consulta sql. Sou Epidemiologista e não tenho conhecimento disso.

Você se importaria de me dar uma sequência de comandos SQL que eu possa executar no postgresql para criar um esquema e um banco de dados nesse esquema?

Desculpem a demora aqui envio como um esquema para criar

CREATE TABLE schema_name.table_name
(
caractere codigo variando (3),
personagem nombre variando (51),
caráter do continente variável (7)
)

19/03/2014 18:56 GMT-03: 00 Hadley Wickham [email protected] :

Você se importaria de me dar uma sequência de comandos SQL que eu possa executar
postgresql para criar um esquema e um banco de dados nesse esquema?

Responda diretamente a este e-mail ou visualize-o em Gi tHubhttps: //github.com/hadley/dplyr/issues/244#issuecomment -38112148
.

Diego garcilazo
Médico
Departamento Programas de Salud
Instituto Nacional de Enfermedades Respiratorias
Av. Blas Parera 8260 // Santa Fé // Argentina // 0342 - 4896850
http://www.anlis.gov.ar/inst/iner/

Acho que existem basicamente duas opções aqui:

1. Caso especial escapando sempre que houver um ponto no identificador. Isso significaria que x.y seria uma fuga para "x"."y" . Isso tem a vantagem de ser muito sucinto, pois tem a desvantagem de que tabelas traduzidas de R para SQL não podem usar . em nomes de campo (provavelmente não é muito comum).
2. Use um novo mecanismo de escape. Provavelmente, a maneira mais fácil de fazer isso seria estender ident() para receber vários argumentos, por exemplo, ident("x", "y") . Alternativamente, poderia definir dot() que faz NSE para permitir que você escreva dot(x, y) . Isso é mais digitação, mas não quebra nenhum código existente.

Isso é importante tanto para nomes de tabelas (por exemplo, schema.table ) e possivelmente para eliminar a ambigüidade de nomes de campos em junções (por exemplo, table.field )

No momento, estou inclinado para a função dot() explícita, porque mudar a forma como o escape funciona globalmente parece arriscado.

Hmmmm, para este caso de uso, você pode apenas fazer:

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

E algum outro código para referência futura (não teve sucesso)

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"))

Oi Hadley,

Estou tendo o mesmo problema e o aninhamento parece ser um problema de desempenho (no meu caso, um problema sério, pois estou trabalhando com dados com centenas de milhões de linhas). Você poderia explicar por que sua última tentativa falhou?

Obrigado

FWIW, para alguns casos de uso, um idioma útil é:

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

Então, as consultas subsequentes usando essa conexão estão dentro desse esquema.

Oi Harlan,

obrigado - e já estou usando algo parecido (exceto que estou expandindo o caminho de pesquisa pelo esquema. Mas isso só ajuda até agora. Se você tiver tabelas com os mesmos nomes em 2 esquemas, não vai.

De qualquer forma, eu estava me perguntando por que não sobrecarregar o sinal '$' no tradutor SQL base_scalar.

Até faria sentido de uma perspectiva r

a $ b $ c, a haveria um ambiente (ou seja, um esquema), uma tabela ba e uma coluna ca. A única coisa que precisa ser corrigida é tbl_sql, que não deve verificar de maneira tão simples se nome_tabela existe no banco de dados. Em vez disso, ele poderia verificar se uma instrução "SELECT" faz parte da consulta SQL e, se não, adicionar um SELECT * na frente e verificar as variáveis ​​desta forma.

Nesse caso, pode-se até habilitar o NSE para a função tbl?

Ah sim, mais um comentário:

dbSendQuery

frequentemente não funciona para RJDBC (pelo menos com vertica). A consulta acima, ou seja, SET search_path TO ...

não retorna um resultado. dbSendQuery espera um. Para vertica, isso não funciona e é necessário usar dbSendUpdate. Esse também é o caso para MySQL (ou pelo menos dbSendUpdate não falha para MySQL)?

Gosto da ideia de sobrecarregar $ . Definitivamente pensarei nisso na próxima vez em que trabalhar no dplyr.

@hhoeflin , você tentou RPostgreSQL em vez de RJDBC para falar com Vértica?

Não - não tinha ideia de que RPostgreSQL é uma opção. Em qualquer caso - o backend vertica já está implementado para RJDBC. No entanto, tentei e tive problemas, pois as tabelas do postgres que ele está tentando acessar para descobrir quais tabelas existem no banco de dados parecem ser diferentes.

Isso está lentamente sendo resolvido por meio do DBI: https://github.com/rstats-db/DBI/issues/24