* 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.
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..).
Thanks,
Stephen