Re: Re: [HACKERS] Re: [SQL] MAX() of 0 records.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Chris Bitmead <chris(at)bitmead(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: [HACKERS] Re: [SQL] MAX() of 0 records.
Date: 2000-07-07 16:35:14
Message-ID: 10551.962987714@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers pgsql-sql

Chris Bitmead <chris(at)bitmead(dot)com> writes:
> Another observation is that if the WHERE clause is successful, it seems
> to update the first record in the target relation that it finds which is
> a pretty random result.

Wouldn't surprise me --- leastwise, you will get a random one of the
input ctid values emitted into the aggregated SELECT row. Offhand I'd
have expected the last-scanned one, not the first-scanned, but the
point is that the behavior is dependent on the implementation's choice
of scanning order. This is exactly the uncertainty that the check for
"attribute must be GROUPed or used in an aggregate function" is designed
to protect you from. But ctid is (currently) escaping that check.

It seems to me that we have two reasonable ways to proceed:

1. Forbid aggregates at the top level of UPDATE. Then you'd need to do
a subselect, perhaps something like
UPDATE foo
SET bar = (SELECT min(f1) FROM othertab
WHERE othertab.keycol = foo.keycol)
WHERE condition-determining-which-foo-rows-to-update
if you wanted to use an aggregate. This is pretty ugly, especially so
if the outer WHERE condition is itself dependent on scanning othertab
to see if there are matches to the foo row.

2. Do an implicit GROUP BY ctid as I suggested last night. I still
don't see any holes in that idea, but I am still worried that there
might be one.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2000-07-07 16:35:37 Re: Factorial operator gets parser error in psql.
Previous Message Robert B. Easter 2000-07-07 16:28:11 Factorial operator gets parser error in psql.

Browse pgsql-hackers by date

  From Date Subject
Next Message Chris Bitmead 2000-07-07 16:50:53 libpq / SQL3
Previous Message Bruce Momjian 2000-07-07 16:19:03 Re: SQL float types

Browse pgsql-sql by date

  From Date Subject
Next Message Tom Lane 2000-07-07 16:52:29 Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios...
Previous Message Bruce Momjian 2000-07-07 16:02:30 Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios...