On 2013-12-26 15:25:41 -0800, Robert Haas wrote: > On Tue, Dec 24, 2013 at 6:22 AM, Andres Freund <and...@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 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. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
