On 2013-12-26 15:25:41 -0800, Robert Haas wrote:
> On Tue, Dec 24, 2013 at 6:22 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> > If system columns don't have an overhead anymore, I fail to see the
> > advantage that functions have over simply accessing parts of the row in
> > the normal way parts of rows are accessed. The only reasoning I can see
> > is lessening the likelihood of conflicts - but that's essentially only
> > solved via namespaced pg_ prefixes for functions as well.
>
> 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
forthe individual columns.
* By nature of being a record returning function it's awkward to use if you want the individual columns because you
essentiallyneed 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
systemcolumns itself...
* It's imo harder to spot differenced between versions in record types than columns.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services