Re: preserving forensic information when we freeze

On Fri, Dec 27, 2013 at 6:15 AM, Stephen Frost <sfrost@snowman.net> wrote:
> * Andres Freund (andres@2ndquadrant.com) wrote:
>> On 2013-12-26 15:25:41 -0800, Robert Haas wrote:
>> > I dunno, I just have an uneasy feeling about it.  I guess if
>> > everyone's happy to add pg_infomask and pg_infomask2 as new system
>> > columns, we could go that route.  For my part, I think that functions
>> > are a real extensibility mechanism and hidden system columns are a
>> > crock I'd rather not propagate.  But I just work here, and I'll give
>> > way if the consensus is otherwise.
>>
>> I am happy enough with functions as well, so I certainly won't
>> fundamentally block that path after a bit more discussion. My problems
>> with the function approach may in parts even be fixable, making me
>> prefer it:
>> * It's slower. It refetches the tuple from s_b/disk, it builds a row
>>   type to return, which then needs to get accessed for the individual
>>   columns.
>> * By nature of being a record returning function it's awkward to use if you
>>   want the individual columns because you essentially need to use
>>   LATERAL or you re-execute the function for each column.
>> * It's awkward to use because you need to need to pass
>>   tableoid/ctid. That's quite some notational overhead, relying on
>>   system columns itself...
>> * It's imo harder to spot differenced between versions in record types than
>>   columns.
>
> For my 2c, I tend to agree w/ Andres on this one.  I like the *idea* of
> having a function instead, but, practically, it doesn't really work.
> Perhaps if the 'function' approach was one-function-per-column and we
> could remove the need for the function to take any arguments, but I'm
> not sure we've really got something better than what we have now.

I'm not sure what you mean by "doesn't work", because it clearly does
work.  I've already posted a patch.  You may find it ugly, but that's
not the same as not working.

> Hindsight being what it is, perhaps we should have stuffed the system
> columns into a complex type instead of having individual columns, but
> I'm not sure changing that now would be worth the backwards
> compatibility break (yes, I know they're system columns, but I've seen
> more than one case of using ctid to break ties in otherwise identical
> rows..).

Well, if the consensus is in favor of adding more system columns,
that's not my first choice, but I'm OK with it.  However, I wonder how
we plan to name them.  If we add pg_infomask and pg_infomask2, it
won't be consistent with the existing naming convention which doesn't
include any kind of pg-prefix, but if we don't use such a prefix then
every column we add further pollutes the namespace.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company