Row comparison for tables (was Re: vacuum, performance, and MVCC) - Mailing list pgsql-hackers

From Tom Lane
Subject Row comparison for tables (was Re: vacuum, performance, and MVCC)
Date
Msg-id 10199.1151029817@sss.pgh.pa.us
Whole thread Raw
In response to Re: vacuum, performance, and MVCC  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> Jim Nasby <jnasby@pervasive.com> writes:
>> What would be nice to add is the ability to perform that check more  
>> easily. As of 8.1...
>> ...
>> if NEW=OLD then
>> ...
>> ERROR:  operator does not exist: test = test
>> HINT:  No operator matches the given name and argument type(s). You  
>> may need to add explicit type casts.

> Hmm, there seems to be some asymmetry in the handling, because it works
> for anonymous row constructors:
> regression=# select row(a.q1,a.q2) = row(a.q1,a.q2) from int8_tbl a;

I poked into this a little, and it seems like the most flexible answer
might be for "foo.*" inside a ROW construct to behave the way that it
does at the top level of a SELECT list --- that is, implicitly expand to
a list of all the columns of foo.  You'd have to write the mentioned
test as
if row(new.*) = row(old.*) then ...

but there is some additional flexibility because you could form rows
from combinations of things, eg
row(foo.*, bar, baz.*)

I can't find anything suggesting this syntax in the SQL99 spec, but
I don't think they expect equality to work on two unadorned table names
either.

Not sure if there are any backwards-compatibility issues.  Right now the
system takes this syntax as creating a rowtype column within a rowtype,
which is possibly of some use but I kinda doubt people are doing much
with it.  In any case, if you did want that behavior you could still get
it by leaving off the ".*".

Implementation would be pretty trivial, we'd just have to put logic into
transformRowExpr() comparable to what transformTargetList() does for
"foo.*" cases.  With a little bit of refactoring, the code could be shared.

Comments?
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Qingqing Zhou"
Date:
Subject: Small overhead run time memory trace (Was Re: shall we have a TRACE_MEMORY mode)
Next
From: Gavin Sherry
Date:
Subject: Re: vacuum, performance, and MVCC