Dplyr: No puedo conectar postgresql schema.table con el paquete dplyr

@hadley pensando en tu respuesta, se me ocurrió escribir la oración SQL completa

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

y allí pude conectarme al esquema y la tabla. Muchas gracias. - Diego

Solo iba a publicar este mismo problema cuando trabajara con Greenplum. Tu método sql resolvió mi problema.

Estoy feliz con eso. Lo único que me preocupa es que en el enunciado sql se observa lo siguiente

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

cuando se realiza cualquier agrupación. Hay una subconsulta después de FROM y no sé si esto tendrá algún tipo de problema con la eficiencia de la consulta sql. Soy epidemiólogo y no lo sé.

¿Le importaría darme una secuencia de comandos SQL que pueda ejecutar en postgresql para crear un esquema y una base de datos en ese esquema?

Perdón por la demora aquí, envío como crear un esquema

CREAR TABLA nombre_esquema.nombre_tabla
(
carácter codigo variable (3),
nombre de carácter variable (51),
carácter continente variable (7)
)

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

¿Le importaría darme una secuencia de comandos SQL que pueda ejecutar
postgresql para crear un esquema y una base de datos en ese esquema?

Responda a este correo electrónico directamente o véalo en Gi
.

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

Creo que básicamente hay dos opciones aquí:

1. Caso especial de escape siempre que haya un punto en el identificador. Esto significaría que x.y sería un escape a "x"."y" . Esto tiene la ventaja de ser muy conciso, tiene la desventaja de que las tablas traducidas de R a SQL no pueden usar . en los nombres de los campos (probablemente no es muy común).
2. Utilice un nuevo mecanismo de escape. Probablemente la forma más fácil de hacer esto sería extender ident() para tomar múltiples argumentos, por ejemplo, ident("x", "y") . Alternativamente, podría definir dot() que hace NSE para permitirle escribir dot(x, y) . Esto es más tipeo, pero se garantiza que no romperá ningún código existente.

Esto es importante tanto para los nombres de las tablas (por ejemplo, schema.table ) como posiblemente para eliminar la ambigüedad de los nombres de los campos en las combinaciones (por ejemplo, table.field )

Actualmente me estoy inclinando hacia la función explícita dot() , porque cambiar cómo funciona el escape a nivel mundial parece arriesgado.

Hmmmm, para este caso de uso, puedes hacer lo siguiente:

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

Y algún otro código para referencia futura (no tuvo éxito)

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

Hola Hadley,

Tengo el mismo problema y el anidamiento parece ser un problema de rendimiento (en mi caso, uno serio, ya que estoy trabajando con datos con cientos de millones de filas). ¿Podría explicar por qué falló su último intento?

Gracias

FWIW, para algunos casos de uso, un modismo útil es:

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

Luego, las consultas posteriores que utilizan esa conexión están dentro de ese esquema.

Hola harlan

gracias, y ya estoy usando algo así (excepto que estoy expandiendo la ruta de búsqueda por el esquema. Pero solo ayuda hasta ahora. Si tiene tablas con los mismos nombres en 2 esquemas, no lo hará.

De todos modos, me preguntaba por qué no sobrecargar el signo '$' en el traductor SQL base_scalar.

Incluso tendría sentido desde una perspectiva r

a $ b $ c, habría un entorno (es decir, un esquema), una tabla ba y una columna ca. El único pensamiento que debe arreglarse es tbl_sql, que no debería verificar de una manera tan simple si table_name existe en la base de datos. En su lugar, podría verificar si una instrucción "SELECT" es parte de la consulta SQL y si no, agregar un SELECT * al frente y verificar las variables de esta manera.

En este caso, ¿podría incluso habilitar NSE para la función tbl?

Oh sí, un comentario más:

dbSendQuery

a menudo no funciona para RJDBC (al menos con vertica). La consulta anterior, es decir, SET search_path TO ...

no devuelve un resultado. dbSendQuery espera uno. Para vertica, esto no funciona y hay que usar dbSendUpdate. ¿Es ese también el caso de MySQL (o al menos dbSendUpdate no falla para MySQL)?

Me gusta la idea de sobrecargar $ . Definitivamente lo pensaré la próxima vez que trabaje en dplyr.

@hhoeflin, ¿ ha probado RPostgreSQL en lugar de RJDBC para hablar con vertica?

No, no tenía idea de que RPostgreSQL es una opción. En cualquier caso, el backend de vertica ya está implementado para RJDBC. Sin embargo, lo intenté y encontré problemas ya que las tablas de postgres a las que está tratando de acceder para averiguar qué tablas existen en la base de datos parecen ser diferentes.

Esto se está resolviendo lentamente a través de DBI: https://github.com/rstats-db/DBI/issues/24