From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: VARIANT / ANYTYPE datatype |
Date: | 2011-05-04 20:33:25 |
Message-ID: | BANLkTi=4Cpt1SVFBv75eO=4zxpiLNL8BSA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, May 4, 2011 at 2:55 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> On 05/04/2011 01:36 PM, Tom Lane wrote:
>>
>>> The main idea is to be able to store column values in an audit table
>>> like this:
>>> old_value variant
>>> new_value variant
>>> Currently, they use text for old_value and new_value, but this is, of
>>> course, not very satisfactory.
>>
>> Just out of curiosity, what actual functionality gain would ensue over
>> just using text? It seems like doing anything useful with the audit
>> table contents would still require casting the column to text, or the
>> moral equivalent of that.
>>
>
> Yeah, I've been down this road once or twice, and I think that's the $64
> question.
>
> I wrote a custom audit app two or three years ago. After several iterations
> the customer and I found that using an hstore for the old/new (or old record
> / changeset, which is what we actually use) was the most suitable for our
> use.
yeah -- +1 on that method. I think it's really the right way to go
with the recent hstore enhancements.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2011-05-04 20:36:00 | Re: GSoC 2011: Fast GiST index build |
Previous Message | Tomasz Chmielewski | 2011-05-04 20:27:44 | Re: 'SGT DETAIL: Could not open file "pg_clog/05DC": No such file or directory' - what to do now? |