Robert Haas <robertmh...@gmail.com> writes:
> On Thu, Jan 2, 2014 at 12:26 AM, Greg Stark <st...@mit.edu> wrote:
>> 1) it's a bit weird to go to this effort to eliminate system columns by
>> using a scheme that depends on having a system column -- ctid
> At any rate, my goal isn't really to get rid of system columns, but to
> address Jim Nasby's gripe that the changes thus far committed make it
> difficult to use system columns to determine whether a given tuple has
> been frozen. It sounds like the consensus is that a system column is
> a better way of doing that than a function, so I suppose the next step
> is to try to hammer out the details.
Actually, I thought the function approach was a good proposal. You are
right that func(tab.*) isn't going to work, because it's going to get a
Datum-ified tuple not a pointer to raw on-disk storage. But an inspection
function that's handed a ctid could work.
I don't think that Greg's objection above has much force. The fact of the
matter is that we are never going to be able to get rid of the exposed
tableoid, oid, or ctid columns, because there are too many situations
where those are useful, and are being used, in actual client-application
queries. This is less true however of xmin/xmax/cmin/cmax; we might hope
to deprecate those at the SQL level someday, especially in view of the
fact that we keep whacking around their detailed meanings, with few user
complaints.
And I really really *don't* want to see us bloating pg_attribute, nor
infringing further on application column namespace, by adding even more
exposed columns. So -1 for just blindly doing that.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
