From: | Jaime Casanova <jaime(at)2ndquadrant(dot)com> |
---|---|
To: | alvherre <alvherre(at)commandprompt(dot)com> |
Cc: | Gerardo Herzig <gherzig(at)fmed(dot)uba(dot)ar>, pgsql-es-ayuda <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: castear variable tipo RECORD a TEXT[] |
Date: | 2010-05-28 04:44:51 |
Message-ID: | AANLkTilZAVIEqKcsyM1LIu6vS9dBzepS0WZ2KItZY5cm@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
2010/5/27 alvherre <alvherre(at)commandprompt(dot)com>:
>
>
> A todo esto, ¿alguna razón para no usar tablelog de pgfoundry?
>
De hecho el mayor problema que tiene tablelog es que si agrego una
nueva columna a la tabla me toca hacer maromas (lease botar el
trigger, crear una nueva tabla, pasar los datos, crear el trigger
apuntando a la nueva tabla) para mantener los datos antiguos de
auditoria y no hay mejora en ese aspecto con esta alternativa...
razones para si usar tablelog:
- me toca explicar menos cosas para que el *dba* pueda consultar en la
auditoria ;)
- en teoria puedes restaurar la tabla a como estaba antes de que
alguien hiciera algun INSERT/UPDATE/DELETE (no he hecho la prueba pero
me parece que eso es algo de hazlo rapido antes que sea tarde :)
imagino que tablelog seria mejor si las columnas adicionales
estuvieran al inicio y no al final...
BTW, el ejemplo que pusiste al final me parecio bastante interesante...
--
Jaime Casanova www.2ndQuadrant.com
Soporte y capacitación de PostgreSQL
From | Date | Subject | |
---|---|---|---|
Next Message | MOLINA BRAVO FELIPE DE JESUS | 2010-05-28 08:50:50 | Re: COPY FROM |
Previous Message | alvherre | 2010-05-28 01:20:47 | Re: castear variable tipo RECORD a TEXT[] |