Timestamptz en valores históricos

Estimados, estoy tratando de cargar desde un csv unos datos a una tabla. El
problema es que el csv algunos campos que son numeros ( integer o real )
trate "-" en vez de un null. Mi pregunta es ¿ Existe la posibilidad de
insertarlos mediante copy y que omina si no son numeros?. Ya que al
insertarlo directamente me da error de sintaxis. He pensado en procesar el
archivo primero ( es bastante grande ), lo cual no es complejo pero queria
saber si se puede directamente .

Saludos y gracias

--

Maximiliano Riffo Donoso

Maximiliano Riffo escribió:
> Estimados, estoy tratando de cargar desde un csv unos datos a una tabla. El
> problema es que el csv algunos campos que son numeros ( integer o real )
> trate "-" en vez de un null. Mi pregunta es ¿ Existe la posibilidad de
> insertarlos mediante copy y que omina si no son numeros?. Ya que al
> insertarlo directamente me da error de sintaxis. He pensado en procesar el
> archivo primero ( es bastante grande ), lo cual no es complejo pero queria
> saber si se puede directamente .

pgLoader ?

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

No conocia pgLoader. Lo voy a probar . Gracias

El 29 de diciembre de 2014, 18:22, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
escribió:

> Maximiliano Riffo escribió:
> > Estimados, estoy tratando de cargar desde un csv unos datos a una tabla.
> El
> > problema es que el csv algunos campos que son numeros ( integer o real )
> > trate "-" en vez de un null. Mi pregunta es ¿ Existe la posibilidad de
> > insertarlos mediante copy y que omina si no son numeros?. Ya que al
> > insertarlo directamente me da error de sintaxis. He pensado en procesar
> el
> > archivo primero ( es bastante grande ), lo cual no es complejo pero
> queria
> > saber si se puede directamente .
>
> pgLoader ?
>
> --
> Álvaro Herrera http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>

--

Maximiliano Riffo Donoso

Buenas tardes lista.
Tengo una duda acerca del timestamptz en postgres, en lugares con
cambio de horario de verano/invierno.
Estuve leyendo un post de Alvaro Herrera muy clarito respecto al uso de
timestamptz y evitar el timestamp sólo, y fue muy clarificador, pero no
termino de comprender lo siguiente:
El timezonetz siempre guarda la hora GMT y hace la conversión a la
zona local, la pregunta es, en caso de información histórica, donde en
el horario de verano se trata de UTC-2 y en invierno UTC-3, los valores
insertados durante el período UTC-2 serán mostrados como UTC-3 cuando la
zona local vuelva a cambiar? existe en postgres una forma de controlar o
guardar en conjunto la TZ o se debe pensar en controlarlo en el desarrollo?

Saludos y muchas gracias

Mario Sileone.

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripcin:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Hola Mario, tanto tiempo.

En el tzdata del SO está toda la información de cambios de husos horarios
pasados (podés verlo bajando las fuentes), por lo que postgres y cualquier
otra aplicación que consulte una hora local usando el tzdata instalado en
el SO pueden saber cual fue la hora local de cualquier hora del pasado que
este en UTC.

Espero haya quedado claro.

Un abrazo!

El 30 de diciembre de 2014, 18:46, Mario Sileone (GM) <msileone(at)gmail(dot)com>
escribió:

> Buenas tardes lista.
> Tengo una duda acerca del timestamptz en postgres, en lugares con
> cambio de horario de verano/invierno.
> Estuve leyendo un post de Alvaro Herrera muy clarito respecto al uso de
> timestamptz y evitar el timestamp sólo, y fue muy clarificador, pero no
> termino de comprender lo siguiente:
> El timezonetz siempre guarda la hora GMT y hace la conversión a la
> zona local, la pregunta es, en caso de información histórica, donde en el
> horario de verano se trata de UTC-2 y en invierno UTC-3, los valores
> insertados durante el período UTC-2 serán mostrados como UTC-3 cuando la
> zona local vuelva a cambiar? existe en postgres una forma de controlar o
> guardar en conjunto la TZ o se debe pensar en controlarlo en el desarrollo?
>
> Saludos y muchas gracias
>
> Mario Sileone.
>
>
>
>
> -
> Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org
> )
> Para cambiar tu suscripción:
> http://www.postgresql.org/mailpref/pgsql-es-ayuda
>

--
Martín Marqués
select 'martin.marques' || '@' || 'gmail.com'
DBA, Programador, Administrador

Como estás Martín, gracias por tu respuesta y perdón por la demora.
Entiendo. esto significa que cualquier consulta histórica en fechas
con distinto timestamp consultarían la variación de la hora durante el
año o los años anteriores, devolviendo por ejemplo -3 en un caso y si es
anterior al horario de invierno -4? de ser así es perfecto.
Por otro lado leí que, no es conveniente en tablas particionadas
por fechas tener un timestamptz, sino que se debería utilizar timestamp
sólo, esto en cuanto puede afectar el split de tablas?

saludos y gracias

Mario Sileone.

El 11/01/2015 a las 18:12, Martín Marqués escribió:
> Hola Mario, tanto tiempo.
>
> En el tzdata del SO está toda la información de cambios de husos
> horarios pasados (podés verlo bajando las fuentes), por lo que
> postgres y cualquier otra aplicación que consulte una hora local
> usando el tzdata instalado en el SO pueden saber cual fue la hora
> local de cualquier hora del pasado que este en UTC.
>
> Espero haya quedado claro.
>
> Un abrazo!
>
>
> El 30 de diciembre de 2014, 18:46, Mario Sileone (GM)
> <msileone(at)gmail(dot)com <mailto:msileone(at)gmail(dot)com>> escribió:
>
> Buenas tardes lista.
> Tengo una duda acerca del timestamptz en postgres, en lugares
> con cambio de horario de verano/invierno.
> Estuve leyendo un post de Alvaro Herrera muy clarito respecto al
> uso de timestamptz y evitar el timestamp sólo, y fue muy
> clarificador, pero no termino de comprender lo siguiente:
> El timezonetz siempre guarda la hora GMT y hace la conversión
> a la zona local, la pregunta es, en caso de información histórica,
> donde en el horario de verano se trata de UTC-2 y en invierno
> UTC-3, los valores insertados durante el período UTC-2 serán
> mostrados como UTC-3 cuando la zona local vuelva a cambiar? existe
> en postgres una forma de controlar o guardar en conjunto la TZ o
> se debe pensar en controlarlo en el desarrollo?
>
> Saludos y muchas gracias
>
> Mario Sileone.
>
>
>
>
> -
> Enviado a la lista de correo pgsql-es-ayuda
> (pgsql-es-ayuda(at)postgresql(dot)org <mailto:pgsql-es-ayuda(at)postgresql(dot)org>)
> Para cambiar tu suscripción:
> http://www.postgresql.org/mailpref/pgsql-es-ayuda
>
>
>
>
> --
> Martín Marqués
> select 'martin.marques' || '@' || 'gmail.com <http://gmail.com>'
> DBA, Programador, Administrador

Mario Sileone (GM) escribió:

> Por otro lado leí que, no es conveniente en tablas particionadas por
> fechas tener un timestamptz, sino que se debería utilizar timestamp sólo,
> esto en cuanto puede afectar el split de tablas?

No es que "no convenga". Lo que sucede simplemente es que ciertas
consultas pueden escanear todas las particiones en vez de excluir las
que podrían en teoría excluirse, porque las consultas con timestamptz
van a depender del valor del parámetro de configuración TimeZone y el
optimizador se va a negar a aplicar el "constraint exclusion" en esos
casos. No tengo claro si es totalmente imposible usarlo o es sólo
muy incómodo. Tendrías que experimentar usando el operador AT TIME
ZONE, que convierte un timestamptz en timestamp (y viceversa) para
estudiar si puede hacerse para las consultas que necesitas.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Gracias Alvaro por tu respuesta, voy a revisar de utilizar el operador
AT TIME y revisar si todo funciona.

Saludos y gracias.

Mario.

El 22/01/2015 a las 16:47, Alvaro Herrera escribió:
> Mario Sileone (GM) escribió:
>
>> Por otro lado leí que, no es conveniente en tablas particionadas por
>> fechas tener un timestamptz, sino que se debería utilizar timestamp sólo,
>> esto en cuanto puede afectar el split de tablas?
> No es que "no convenga". Lo que sucede simplemente es que ciertas
> consultas pueden escanear todas las particiones en vez de excluir las
> que podrían en teoría excluirse, porque las consultas con timestamptz
> van a depender del valor del parámetro de configuración TimeZone y el
> optimizador se va a negar a aplicar el "constraint exclusion" en esos
> casos. No tengo claro si es totalmente imposible usarlo o es sólo
> muy incómodo. Tendrías que experimentar usando el operador AT TIME
> ZONE, que convierte un timestamptz en timestamp (y viceversa) para
> estudiar si puede hacerse para las consultas que necesitas.
>

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda