Re: preserving forensic information when we freeze

Robert,

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Fri, Dec 27, 2013 at 6:15 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > 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.

I meant *practically*, it doesn't work. By which, I mean, "it sucks" as
a solution. :)

> > 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.

Yeah, I agree that it gets a bit ugly... What would you think of doing
*both*? Keep the existing system columns for backwards compatibility,
but then also have a complex 'pg_header' type which provides all of the
existing columns, as well as infomask && infomask2 ...?

I've not looked into any of the implementation complexity, but it might
give us a path to providing *just* the 'pg_header' (or whatever color we
end up making that bike shed...) complex type with all the system
columns available under it, maybe only using that in 10.0?

Thanks,

Stephen