Row comparison for tables (was Re: vacuum, performance, and MVCC)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jim Nasby <jnasby(at)pervasive(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Row comparison for tables (was Re: vacuum, performance, and MVCC)
Date: 2006-06-23 02:30:17
Message-ID: 10199.1151029817@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Jim Nasby <jnasby(at)pervasive(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Browne 2006-06-23 03:02:42 Re: vacuum, performance, and MVCC
Previous Message Gavin Sherry 2006-06-23 02:30:03 Re: vacuum, performance, and MVCC