On Fri, Dec 20, 2013 at 7:51 AM, Andres Freund <and...@2ndquadrant.com> wrote:
> On 2013-12-20 07:47:17 -0500, Robert Haas wrote:
>> On Fri, Dec 20, 2013 at 7:22 AM, Andres Freund <and...@2ndquadrant.com>
>> >> 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.
>> > I was wondering whether we couldn't just pass pg_tuple_header() a whole
>> > row, instead of having the user manually pass in reloid and ctid. I
>> > think that should actually work in the interesting scenarios.
>> I wondered that, too, but it's not well-defined for all tuples. What
>> happens if you pass in constructed tuple rather than an on-disk tuple?
> Those should be discernible I think, t_self/t_tableOid won't be set for
> generated tuples.
Hmm. That might work.
I think the immediate problem is to decide whether this patch ought to
make the xmin column display the result of GetXmin() or GetRawXmin().
Thoughts on that?
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: