Re: preserving forensic information when we freeze - Mailing list pgsql-hackers

<p dir="ltr">> I fail to see why.  What is so ugly about this:<p dir="ltr">> select x.* from pgbench_accounts a,
pg_tuple_header(a.tableoid,a.ctid) x;<p dir="ltr">Two points: <p dir="ltr">1) it's a bit weird to go to this effort to
eliminatesystem columns by using a scheme that depends on having a system column -- ctid<p dir="ltr">2) refetching a
rowcould conceivably end up retrieving different data than was present when the row was originally read. (In some cases
thatmight actually be the intended behaviour)<p dir="ltr">If this came up earlier I'm sorry but I suppose it's too hard
tohave a function like foo(tab.*) which magically can tell that the record is a heap tuple and look in the header? And
presumablythrow an error if passed a non heap tuple.<p dir="ltr">-- <br /> greg<div class="gmail_quote">On 1 Jan 2014
21:34,"Robert Haas" <<a href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>> wrote:<br
type="attribution"/><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">On Fri, Dec 27, 2013 at 9:24 PM, Stephen Frost <<a
href="mailto:sfrost@snowman.net">sfrost@snowman.net</a>>wrote:<br /> >> I'm not sure what you mean by "doesn't
work",because it clearly does<br /> >> work.  I've already posted a patch.  You may find it ugly, but that's<br
/>>> not the same as not working.<br /> ><br /> > I meant *practically*, it doesn't work.  By which, I
mean,"it sucks" as<br /> > a solution. :)<br /><br /> I fail to see why.  What is so ugly about this:<br /><br />
selectx.* from pgbench_accounts a, pg_tuple_header(a.tableoid, a.ctid) x;<br /><br /> It may be true that that query
wouldn'thave worked before Tom added<br /> LATERAL, but he did add LATERAL and we have it now and nobody's going<br />
tocare about this function on versions that haven't got LATERAL,<br /> because it won't exist there anyway.  The whole
pointof adding<br /> features like LATERAL (which doesn't even appear in that query,<br /> interestingly enough) is
thatit was really annoying to use functions<br /> like this before we had it.  But now we *do* have it, so the fact
a<br/> function like this would have been annoying to use in older releases<br /> isn't a reason not to add it now.<br
/><br/> I will admit that performance may be a reason.  After pgbench -i:<br /><br /> rhaas=# explain analyze select
xmaxfrom pgbench_accounts;<br />                                                        QUERY PLAN<br />
------------------------------------------------------------------------------------------------------------------------<br
/> Seq Scan on pgbench_accounts  (cost=0.00..2640.00 rows=100000<br /> width=4) (actual time=0.009..14.950 rows=100000
loops=1)<br/>  Total runtime: 20.354 ms<br /> (2 rows)<br /><br /> rhaas=# explain analyze select
(pg_tuple_header(tableoid,ctid)).xmax<br/> from pgbench_accounts;<br />                                                
       QUERY PLAN<br />
--------------------------------------------------------------------------------------------------------------------------<br
/> Seq Scan on pgbench_accounts  (cost=0.00..2890.00 rows=100000<br /> width=10) (actual time=0.023..314.783
rows=100000loops=1)<br />  Total runtime: 322.714 ms<br /> (2 rows)<br /><br /> >> > Hindsight being what it
is,perhaps we should have stuffed the system<br /> >> > columns into a complex type instead of having
individualcolumns, but<br /> >> > I'm not sure changing that now would be worth the backwards<br /> >>
>compatibility break (yes, I know they're system columns, but I've seen<br /> >> > more than one case of
usingctid to break ties in otherwise identical<br /> >> > rows..).<br /> >><br /> >> Well, if the
consensusis in favor of adding more system columns,<br /> >> that's not my first choice, but I'm OK with it.
 However,I wonder how<br /> >> we plan to name them.  If we add pg_infomask and pg_infomask2, it<br /> >>
won'tbe consistent with the existing naming convention which doesn't<br /> >> include any kind of pg-prefix, but
ifwe don't use such a prefix then<br /> >> every column we add further pollutes the namespace.<br /> ><br />
>Yeah, I agree that it gets a bit ugly...  What would you think of doing<br /> > *both*?  Keep the existing
systemcolumns for backwards compatibility,<br /> > but then also have a complex 'pg_header' type which provides all
ofthe<br /> > existing columns, as well as infomask && infomask2 ...?<br /><br /> I don't really see what
thataccomplishes, TBH.  If we further modify<br /> the header format in the future, we'll need to modify the
definition<br/> of that type, and that will be a backward-compatibility break for<br /> anyone using it.  Adding new
systemcolumns is probably less<br /> intrusive.<br /><br /> Maybe it's best to just add pg_infomask and pg_infomask2 as
system<br/> columns and not worry about the inconsistency with the naming<br /> convention for existing columns.<br
/><br/> Other opinions?<br /><br /> --<br /> Robert Haas<br /> EnterpriseDB: <a href="http://www.enterprisedb.com"
target="_blank">http://www.enterprisedb.com</a><br/> The Enterprise PostgreSQL Company<br /><br /><br /> --<br /> Sent
viapgsql-hackers mailing list (<a href="mailto:pgsql-hackers@postgresql.org">pgsql-hackers@postgresql.org</a>)<br /> To
makechanges to your subscription:<br /><a href="http://www.postgresql.org/mailpref/pgsql-hackers"
target="_blank">http://www.postgresql.org/mailpref/pgsql-hackers</a><br/></blockquote></div>