On Thu, Dec 19, 2013 at 9:22 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Jim Nasby escribió: >> One thing users will lose in this patch is the ability to reliably see if a >> tuple is frozen via SQL. Today you can do that just by selecting xmin from >> the table. >> >> Obviously people don't generally need to do that... but it's one of those >> things that when you do need it it's incredibly handy to have... would it be >> difficult to expose infomask(2) via SQL, the same way xmin et all are? > > It's already exposed via the pageinspect extension. It's doubtful that > there are many valid cases where you need infomask but don't have access > to that module. > > The real fix seems to ensure that the module is always available.
We could make the code that displays this column do GetXmin rather than GetRawXmin, which would allow this question to be answered, but lose the ability to find the original xmin once the tuple is frozen and break precedent with the xmax and cmin/cmax fields, which return the "raw" value from the tuple header. But I'm OK to go whichever direction people prefer. I think the root of the problem is that nobody's very eager to add more hidden system catalog columns because each one bloats pg_attribute significantly. Currently, we have xmin, xmax, cmin, and cmax columns, and that's basically just a historical artifact at this point. cmin and cmax always return the same value, and the value returned may be neither a cmin nor a cmax but a combo CID. And if you're looking for information that's only in the infomask, good luck. Maybe what we should do is add a function something like pg_tuple_header(tableoid, ctid) that returns a record, maybe something like (rawxmin xid, rawxmax xid, rawcid cid, infomask int, infomask2 int, hoff int). Or perhaps some slightly more cooked version of that information. And then delete the xmin, xmax, cmin, and cmax system columns. That'd save significantly on pg_attribute entries while, at the same time, actually providing more information than we do today. pageinspect is useful, too, but it seems to deal mostly with pages, so I'm not sure it's a natural substitute for something like this. -- 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
