On Fri, Dec 27, 2013 at 6:15 AM, Stephen Frost <sfr...@snowman.net> wrote: > * Andres Freund (and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
