Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackerspgsql-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

pgsql-hackers by date

Next:From: Chris BitmeadDate: 2000-07-07 16:50:53
Subject: libpq / SQL3
Previous:From: Bruce MomjianDate: 2000-07-07 16:19:03
Subject: Re: SQL float types

pgsql-bugs by date

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

pgsql-sql by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group