mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-31 04:47:20 +02:00
513 lines
20 KiB
Plaintext
513 lines
20 KiB
Plaintext
From pgsql-hackers-owner+M15878=candle.pha.pa.us=pgman@postgresql.org Mon Nov 26 18:35:28 2001
|
|
Return-path: <pgsql-hackers-owner+M15878=candle.pha.pa.us=pgman@postgresql.org>
|
|
Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged))
|
|
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fAQNZRf08314
|
|
for <pgman@candle.pha.pa.us>; Mon, 26 Nov 2001 18:35:28 -0500 (EST)
|
|
Received: from postgresql.org (postgresql.org [64.49.215.8])
|
|
by rs.postgresql.org (8.11.6/8.11.6) with ESMTP id fAQNXtR48254
|
|
for <pgman@candle.pha.pa.us>; Mon, 26 Nov 2001 17:34:22 -0600 (CST)
|
|
(envelope-from pgsql-hackers-owner+M15878=candle.pha.pa.us=pgman@postgresql.org)
|
|
Received: from sss.pgh.pa.us ([192.204.191.242])
|
|
by postgresql.org (8.11.3/8.11.4) with ESMTP id fAQNSam38109
|
|
for <pgsql-hackers@postgresql.org>; Mon, 26 Nov 2001 18:28:36 -0500 (EST)
|
|
(envelope-from tgl@sss.pgh.pa.us)
|
|
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
|
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id fAQNSIk16033;
|
|
Mon, 26 Nov 2001 18:28:18 -0500 (EST)
|
|
To: Bruce Momjian <pgman@candle.pha.pa.us>
|
|
cc: Philip Warner <pjw@rhyme.com.au>, pgsql-hackers@postgresql.org
|
|
Subject: Re: [HACKERS] Minor buglet in update...from (I think)
|
|
In-Reply-To: <200111262022.fAQKMtj16709@candle.pha.pa.us>
|
|
References: <200111262022.fAQKMtj16709@candle.pha.pa.us>
|
|
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
|
|
message dated "Mon, 26 Nov 2001 15:22:55 -0500"
|
|
Date: Mon, 26 Nov 2001 18:28:17 -0500
|
|
Message-ID: <16030.1006817297@sss.pgh.pa.us>
|
|
From: Tom Lane <tgl@sss.pgh.pa.us>
|
|
Precedence: bulk
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
Status: ORr
|
|
|
|
Bruce Momjian <pgman@candle.pha.pa.us> writes:
|
|
> Can anyone explain this failure? It still exists in CVS.
|
|
|
|
>> update t1 set f2=count(*) from t2 where t1.f1=2 and t2.f1=t1.f1 ;
|
|
>> ERROR: ExecutePlan: (junk) `ctid' is NULL!
|
|
|
|
As I recall, discussion about fixing that problem trailed off because
|
|
no one could explain what an aggregate means in UPDATE. My thought
|
|
is we should probably forbid the construct entirely (SQL does).
|
|
See previous discussion around 7/7/00.
|
|
|
|
regards, tom lane
|
|
|
|
---------------------------(end of broadcast)---------------------------
|
|
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
|
|
|
From tgl@sss.pgh.pa.us Mon Nov 26 19:28:31 2001
|
|
Return-path: <tgl@sss.pgh.pa.us>
|
|
Received: from sss.pgh.pa.us (root@[192.204.191.242])
|
|
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fAR0SVf13056
|
|
for <pgman@candle.pha.pa.us>; Mon, 26 Nov 2001 19:28:31 -0500 (EST)
|
|
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
|
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id fAR0SVk16312;
|
|
Mon, 26 Nov 2001 19:28:31 -0500 (EST)
|
|
To: Bruce Momjian <pgman@candle.pha.pa.us>
|
|
cc: Philip Warner <pjw@rhyme.com.au>, pgsql-hackers@postgresql.org
|
|
Subject: Re: [HACKERS] Minor buglet in update...from (I think)
|
|
In-Reply-To: <200111270023.fAR0NHJ12366@candle.pha.pa.us>
|
|
References: <200111270023.fAR0NHJ12366@candle.pha.pa.us>
|
|
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
|
|
message dated "Mon, 26 Nov 2001 19:23:17 -0500"
|
|
Date: Mon, 26 Nov 2001 19:28:31 -0500
|
|
Message-ID: <16309.1006820911@sss.pgh.pa.us>
|
|
From: Tom Lane <tgl@sss.pgh.pa.us>
|
|
Status: ORr
|
|
|
|
Bruce Momjian <pgman@candle.pha.pa.us> writes:
|
|
> Oh, so it is the aggregate. What threw me off is that both parts of the
|
|
> WHERE clause are required to cause the failure,
|
|
|
|
Not necessarily; I think it's got more to do with a null aggregate
|
|
result:
|
|
|
|
regression=# create table t1 (f1 datetime);
|
|
CREATE
|
|
regression=# create table t2 (f2 datetime);
|
|
CREATE
|
|
regression=# update t2 set f2 = min(f1) from t1;
|
|
ERROR: ExecutePlan: (junk) `ctid' is NULL!
|
|
regression=# insert into t1 values ('now');
|
|
INSERT 400577 1
|
|
regression=# update t2 set f2 = min(f1) from t1;
|
|
ERROR: ExecutePlan: (junk) `ctid' is NULL!
|
|
regression=# insert into t2 values ('now');
|
|
INSERT 400578 1
|
|
regression=# update t2 set f2 = min(f1) from t1;
|
|
UPDATE 1
|
|
regression=#
|
|
|
|
However the ERROR is only one symptom. The real problem is that the
|
|
calculation that's being done is useless/nonsensical.
|
|
|
|
> I don't see a problem with aggregates in UPDATE,
|
|
|
|
Think harder ... what is the aggregate being taken over, and how do you
|
|
associate the aggregate's single result row with any particular row in
|
|
the UPDATE's target table?
|
|
|
|
regards, tom lane
|
|
|
|
From pgsql-hackers-owner+M15883=candle.pha.pa.us=pgman@postgresql.org Mon Nov 26 19:40:39 2001
|
|
Return-path: <pgsql-hackers-owner+M15883=candle.pha.pa.us=pgman@postgresql.org>
|
|
Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged))
|
|
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fAR0ecf14089
|
|
for <pgman@candle.pha.pa.us>; Mon, 26 Nov 2001 19:40:38 -0500 (EST)
|
|
Received: from postgresql.org (postgresql.org [64.49.215.8])
|
|
by rs.postgresql.org (8.11.6/8.11.6) with ESMTP id fAR0YFR49958
|
|
for <pgman@candle.pha.pa.us>; Mon, 26 Nov 2001 18:37:54 -0600 (CST)
|
|
(envelope-from pgsql-hackers-owner+M15883=candle.pha.pa.us=pgman@postgresql.org)
|
|
Received: from sss.pgh.pa.us ([192.204.191.242])
|
|
by postgresql.org (8.11.3/8.11.4) with ESMTP id fAR0Sjm40352
|
|
for <pgsql-hackers@postgresql.org>; Mon, 26 Nov 2001 19:28:45 -0500 (EST)
|
|
(envelope-from tgl@sss.pgh.pa.us)
|
|
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
|
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id fAR0SVk16312;
|
|
Mon, 26 Nov 2001 19:28:31 -0500 (EST)
|
|
To: Bruce Momjian <pgman@candle.pha.pa.us>
|
|
cc: Philip Warner <pjw@rhyme.com.au>, pgsql-hackers@postgresql.org
|
|
Subject: Re: [HACKERS] Minor buglet in update...from (I think)
|
|
In-Reply-To: <200111270023.fAR0NHJ12366@candle.pha.pa.us>
|
|
References: <200111270023.fAR0NHJ12366@candle.pha.pa.us>
|
|
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
|
|
message dated "Mon, 26 Nov 2001 19:23:17 -0500"
|
|
Date: Mon, 26 Nov 2001 19:28:31 -0500
|
|
Message-ID: <16309.1006820911@sss.pgh.pa.us>
|
|
From: Tom Lane <tgl@sss.pgh.pa.us>
|
|
Precedence: bulk
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
Status: OR
|
|
|
|
Bruce Momjian <pgman@candle.pha.pa.us> writes:
|
|
> Oh, so it is the aggregate. What threw me off is that both parts of the
|
|
> WHERE clause are required to cause the failure,
|
|
|
|
Not necessarily; I think it's got more to do with a null aggregate
|
|
result:
|
|
|
|
regression=# create table t1 (f1 datetime);
|
|
CREATE
|
|
regression=# create table t2 (f2 datetime);
|
|
CREATE
|
|
regression=# update t2 set f2 = min(f1) from t1;
|
|
ERROR: ExecutePlan: (junk) `ctid' is NULL!
|
|
regression=# insert into t1 values ('now');
|
|
INSERT 400577 1
|
|
regression=# update t2 set f2 = min(f1) from t1;
|
|
ERROR: ExecutePlan: (junk) `ctid' is NULL!
|
|
regression=# insert into t2 values ('now');
|
|
INSERT 400578 1
|
|
regression=# update t2 set f2 = min(f1) from t1;
|
|
UPDATE 1
|
|
regression=#
|
|
|
|
However the ERROR is only one symptom. The real problem is that the
|
|
calculation that's being done is useless/nonsensical.
|
|
|
|
> I don't see a problem with aggregates in UPDATE,
|
|
|
|
Think harder ... what is the aggregate being taken over, and how do you
|
|
associate the aggregate's single result row with any particular row in
|
|
the UPDATE's target table?
|
|
|
|
regards, tom lane
|
|
|
|
---------------------------(end of broadcast)---------------------------
|
|
TIP 3: if posting/reading through Usenet, please send an appropriate
|
|
subscribe-nomail command to majordomo@postgresql.org so that your
|
|
message can get through to the mailing list cleanly
|
|
|
|
From pgsql-hackers-owner+M15884=candle.pha.pa.us=pgman@postgresql.org Mon Nov 26 19:49:23 2001
|
|
Return-path: <pgsql-hackers-owner+M15884=candle.pha.pa.us=pgman@postgresql.org>
|
|
Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged))
|
|
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fAR0nNf14894
|
|
for <pgman@candle.pha.pa.us>; Mon, 26 Nov 2001 19:49:23 -0500 (EST)
|
|
Received: from postgresql.org (postgresql.org [64.49.215.8])
|
|
by rs.postgresql.org (8.11.6/8.11.6) with ESMTP id fAR0ijR50260
|
|
for <pgman@candle.pha.pa.us>; Mon, 26 Nov 2001 18:47:51 -0600 (CST)
|
|
(envelope-from pgsql-hackers-owner+M15884=candle.pha.pa.us=pgman@postgresql.org)
|
|
Received: from candle.pha.pa.us (candle.navpoint.com [162.33.245.46])
|
|
by postgresql.org (8.11.3/8.11.4) with ESMTP id fAR0dCm40733
|
|
for <pgsql-hackers@postgresql.org>; Mon, 26 Nov 2001 19:39:12 -0500 (EST)
|
|
(envelope-from pgman@candle.pha.pa.us)
|
|
Received: (from pgman@localhost)
|
|
by candle.pha.pa.us (8.11.6/8.10.1) id fAR0d6d13929;
|
|
Mon, 26 Nov 2001 19:39:06 -0500 (EST)
|
|
From: Bruce Momjian <pgman@candle.pha.pa.us>
|
|
Message-ID: <200111270039.fAR0d6d13929@candle.pha.pa.us>
|
|
Subject: Re: [HACKERS] Minor buglet in update...from (I think)
|
|
In-Reply-To: <16309.1006820911@sss.pgh.pa.us> "from Tom Lane at Nov 26, 2001
|
|
07:28:31 pm"
|
|
To: Tom Lane <tgl@sss.pgh.pa.us>
|
|
Date: Mon, 26 Nov 2001 19:39:06 -0500 (EST)
|
|
cc: Philip Warner <pjw@rhyme.com.au>, pgsql-hackers@postgresql.org
|
|
X-Mailer: ELM [version 2.4ME+ PL90 (25)]
|
|
MIME-Version: 1.0
|
|
Content-Transfer-Encoding: 7bit
|
|
Content-Type: text/plain; charset=US-ASCII
|
|
Precedence: bulk
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
Status: OR
|
|
|
|
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
|
|
> > Oh, so it is the aggregate. What threw me off is that both parts of the
|
|
> > WHERE clause are required to cause the failure,
|
|
>
|
|
> Not necessarily; I think it's got more to do with a null aggregate
|
|
> result:
|
|
>
|
|
> regression=# create table t1 (f1 datetime);
|
|
> CREATE
|
|
> regression=# create table t2 (f2 datetime);
|
|
> CREATE
|
|
> regression=# update t2 set f2 = min(f1) from t1;
|
|
> ERROR: ExecutePlan: (junk) `ctid' is NULL!
|
|
> regression=# insert into t1 values ('now');
|
|
> INSERT 400577 1
|
|
> regression=# update t2 set f2 = min(f1) from t1;
|
|
> ERROR: ExecutePlan: (junk) `ctid' is NULL!
|
|
> regression=# insert into t2 values ('now');
|
|
> INSERT 400578 1
|
|
> regression=# update t2 set f2 = min(f1) from t1;
|
|
> UPDATE 1
|
|
> regression=#
|
|
>
|
|
> However the ERROR is only one symptom. The real problem is that the
|
|
> calculation that's being done is useless/nonsensical.
|
|
>
|
|
> > I don't see a problem with aggregates in UPDATE,
|
|
>
|
|
> Think harder ... what is the aggregate being taken over, and how do you
|
|
> associate the aggregate's single result row with any particular row in
|
|
> the UPDATE's target table?
|
|
|
|
I thought the aggregate would be generated on all rows in the table in
|
|
the pre-transaction version of the table, so in this example:
|
|
|
|
regression=# update t2 set f2 = min(f1) from t1;
|
|
|
|
It places the minimum value of t1.f1 in all t2.f2 rows. Is there
|
|
another way to look at it?
|
|
|
|
--
|
|
Bruce Momjian | http://candle.pha.pa.us
|
|
pgman@candle.pha.pa.us | (610) 853-3000
|
|
+ If your life is a hard drive, | 830 Blythe Avenue
|
|
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
|
|
|
|
---------------------------(end of broadcast)---------------------------
|
|
TIP 3: if posting/reading through Usenet, please send an appropriate
|
|
subscribe-nomail command to majordomo@postgresql.org so that your
|
|
message can get through to the mailing list cleanly
|
|
|
|
From tgl@sss.pgh.pa.us Mon Nov 26 19:51:12 2001
|
|
Return-path: <tgl@sss.pgh.pa.us>
|
|
Received: from sss.pgh.pa.us (root@[192.204.191.242])
|
|
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fAR0pCf14964
|
|
for <pgman@candle.pha.pa.us>; Mon, 26 Nov 2001 19:51:12 -0500 (EST)
|
|
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
|
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id fAR0pDk16384;
|
|
Mon, 26 Nov 2001 19:51:13 -0500 (EST)
|
|
To: Bruce Momjian <pgman@candle.pha.pa.us>
|
|
cc: Philip Warner <pjw@rhyme.com.au>, pgsql-hackers@postgresql.org
|
|
Subject: Re: [HACKERS] Minor buglet in update...from (I think)
|
|
In-Reply-To: <200111270039.fAR0d6d13929@candle.pha.pa.us>
|
|
References: <200111270039.fAR0d6d13929@candle.pha.pa.us>
|
|
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
|
|
message dated "Mon, 26 Nov 2001 19:39:06 -0500"
|
|
Date: Mon, 26 Nov 2001 19:51:13 -0500
|
|
Message-ID: <16381.1006822273@sss.pgh.pa.us>
|
|
From: Tom Lane <tgl@sss.pgh.pa.us>
|
|
Status: ORr
|
|
|
|
Bruce Momjian <pgman@candle.pha.pa.us> writes:
|
|
> I thought the aggregate would be generated on all rows in the table in
|
|
> the pre-transaction version of the table, so in this example:
|
|
> regression=# update t2 set f2 = min(f1) from t1;
|
|
> It places the minimum value of t1.f1 in all t2.f2 rows.
|
|
|
|
This actually is not the most interesting example, because the aggregate
|
|
doesn't depend at all on t2. Try this instead:
|
|
|
|
regression=# create table t1(f1 int);
|
|
CREATE
|
|
regression=# create table t2(f1 int);
|
|
CREATE
|
|
regression=# insert into t1 values(-1);
|
|
INSERT 400599 1
|
|
regression=# insert into t1 values(-2);
|
|
INSERT 400600 1
|
|
regression=# insert into t1 values(-3);
|
|
INSERT 400601 1
|
|
regression=# insert into t2 values(-1);
|
|
INSERT 400602 1
|
|
regression=# insert into t2 values(-2);
|
|
INSERT 400603 1
|
|
regression=# insert into t2 values(-3);
|
|
INSERT 400604 1
|
|
regression=# update t2 set f1 = count(*) from t1;
|
|
UPDATE 1
|
|
regression=# select * from t2;
|
|
f1
|
|
----
|
|
-2
|
|
-3
|
|
9
|
|
(3 rows)
|
|
|
|
regression=#
|
|
|
|
This is certainly broken, but what's the correct behavior?
|
|
Or how about this, which doesn't even use an aggregate:
|
|
|
|
regression=# update t2 set f1 = t1.f1 from t1;
|
|
UPDATE 3
|
|
regression=# select * from t2;
|
|
f1
|
|
----
|
|
-1
|
|
-1
|
|
-1
|
|
(3 rows)
|
|
|
|
regression=#
|
|
|
|
That's surprising too, perhaps, but what would you have expected
|
|
and why?
|
|
|
|
There's a reason why SQL99 forbids joins and aggregates in UPDATE ...
|
|
they're not always well-defined.
|
|
|
|
I had a proposal (GROUP BY ctid) in the older thread for fixing the
|
|
aggregate misbehavior, but it doesn't solve the more general problem
|
|
of a join that produces multiple matches for the same target row.
|
|
Seems like that probably ought to draw an error.
|
|
|
|
regards, tom lane
|
|
|
|
From pgsql-hackers-owner+M15885=candle.pha.pa.us=pgman@postgresql.org Mon Nov 26 20:10:34 2001
|
|
Return-path: <pgsql-hackers-owner+M15885=candle.pha.pa.us=pgman@postgresql.org>
|
|
Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged))
|
|
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fAR1AXf16581
|
|
for <pgman@candle.pha.pa.us>; Mon, 26 Nov 2001 20:10:33 -0500 (EST)
|
|
Received: from postgresql.org (postgresql.org [64.49.215.8])
|
|
by rs.postgresql.org (8.11.6/8.11.6) with ESMTP id fAR12nR50907
|
|
for <pgman@candle.pha.pa.us>; Mon, 26 Nov 2001 19:06:09 -0600 (CST)
|
|
(envelope-from pgsql-hackers-owner+M15885=candle.pha.pa.us=pgman@postgresql.org)
|
|
Received: from candle.pha.pa.us (candle.navpoint.com [162.33.245.46])
|
|
by postgresql.org (8.11.3/8.11.4) with ESMTP id fAR0wHm41320
|
|
for <pgsql-hackers@postgresql.org>; Mon, 26 Nov 2001 19:58:17 -0500 (EST)
|
|
(envelope-from pgman@candle.pha.pa.us)
|
|
Received: (from pgman@localhost)
|
|
by candle.pha.pa.us (8.11.6/8.10.1) id fAR0w6c15346;
|
|
Mon, 26 Nov 2001 19:58:06 -0500 (EST)
|
|
From: Bruce Momjian <pgman@candle.pha.pa.us>
|
|
Message-ID: <200111270058.fAR0w6c15346@candle.pha.pa.us>
|
|
Subject: Re: [HACKERS] Minor buglet in update...from (I think)
|
|
In-Reply-To: <16381.1006822273@sss.pgh.pa.us> "from Tom Lane at Nov 26, 2001
|
|
07:51:13 pm"
|
|
To: Tom Lane <tgl@sss.pgh.pa.us>
|
|
Date: Mon, 26 Nov 2001 19:58:06 -0500 (EST)
|
|
cc: Philip Warner <pjw@rhyme.com.au>, pgsql-hackers@postgresql.org
|
|
X-Mailer: ELM [version 2.4ME+ PL90 (25)]
|
|
MIME-Version: 1.0
|
|
Content-Transfer-Encoding: 7bit
|
|
Content-Type: text/plain; charset=US-ASCII
|
|
Precedence: bulk
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
Status: OR
|
|
|
|
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
|
|
> > I thought the aggregate would be generated on all rows in the table in
|
|
> > the pre-transaction version of the table, so in this example:
|
|
> > regression=# update t2 set f2 = min(f1) from t1;
|
|
> > It places the minimum value of t1.f1 in all t2.f2 rows.
|
|
>
|
|
> This actually is not the most interesting example, because the aggregate
|
|
> doesn't depend at all on t2. Try this instead:
|
|
>
|
|
> regression=# create table t1(f1 int);
|
|
> CREATE
|
|
> regression=# create table t2(f1 int);
|
|
> CREATE
|
|
> regression=# insert into t1 values(-1);
|
|
> INSERT 400599 1
|
|
> regression=# insert into t1 values(-2);
|
|
> INSERT 400600 1
|
|
> regression=# insert into t1 values(-3);
|
|
> INSERT 400601 1
|
|
> regression=# insert into t2 values(-1);
|
|
> INSERT 400602 1
|
|
> regression=# insert into t2 values(-2);
|
|
> INSERT 400603 1
|
|
> regression=# insert into t2 values(-3);
|
|
> INSERT 400604 1
|
|
> regression=# update t2 set f1 = count(*) from t1;
|
|
> UPDATE 1
|
|
> regression=# select * from t2;
|
|
> f1
|
|
> ----
|
|
> -2
|
|
> -3
|
|
> 9
|
|
> (3 rows)
|
|
>
|
|
> regression=#
|
|
>
|
|
> This is certainly broken, but what's the correct behavior?
|
|
|
|
Shouldn't it be 9 because there is no join of t1 and t2?
|
|
I can also see 3 as a valid answer.
|
|
|
|
> Or how about this, which doesn't even use an aggregate:
|
|
>
|
|
> regression=# update t2 set f1 = t1.f1 from t1;
|
|
> UPDATE 3
|
|
> regression=# select * from t2;
|
|
> f1
|
|
> ----
|
|
> -1
|
|
> -1
|
|
> -1
|
|
> (3 rows)
|
|
>
|
|
> regression=#
|
|
>
|
|
> That's surprising too, perhaps, but what would you have expected
|
|
> and why?
|
|
|
|
So it grabs the first match. Seems reasonable because t1 returns more
|
|
than one row.
|
|
|
|
>
|
|
> There's a reason why SQL99 forbids joins and aggregates in UPDATE ...
|
|
> they're not always well-defined.
|
|
|
|
Yes, I see that now.
|
|
|
|
> I had a proposal (GROUP BY ctid) in the older thread for fixing the
|
|
> aggregate misbehavior, but it doesn't solve the more general problem
|
|
> of a join that produces multiple matches for the same target row.
|
|
> Seems like that probably ought to draw an error.
|
|
|
|
Or a NOTICE stating a random row was chosen.
|
|
|
|
--
|
|
Bruce Momjian | http://candle.pha.pa.us
|
|
pgman@candle.pha.pa.us | (610) 853-3000
|
|
+ If your life is a hard drive, | 830 Blythe Avenue
|
|
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
|
|
|
|
---------------------------(end of broadcast)---------------------------
|
|
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
|
|
|
From pgsql-hackers-owner+M4046@hub.org Fri Jun 30 08:55:30 2000
|
|
Received: from hub.org (root@hub.org [216.126.84.1])
|
|
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id HAA17845
|
|
for <pgman@candle.pha.pa.us>; Fri, 30 Jun 2000 07:55:30 -0400 (EDT)
|
|
Received: from hub.org (majordom@localhost [127.0.0.1])
|
|
by hub.org (8.10.1/8.10.1) with SMTP id e5UBuOu21797;
|
|
Fri, 30 Jun 2000 07:56:24 -0400 (EDT)
|
|
Received: from acheron.rime.com.au (root@albatr.lnk.telstra.net [139.130.54.222])
|
|
by hub.org (8.10.1/8.10.1) with ESMTP id e5UBtgu21623
|
|
for <pgsql-hackers@postgresql.org>; Fri, 30 Jun 2000 07:55:44 -0400 (EDT)
|
|
Received: from oberon (Oberon.rime.com.au [203.8.195.100])
|
|
by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id VAA27179
|
|
for <pgsql-hackers@postgresql.org>; Fri, 30 Jun 2000 21:50:24 +1000
|
|
Message-ID: <3.0.5.32.20000630215746.03221df0@mail.rhyme.com.au>
|
|
X-Sender: pjw@mail.rhyme.com.au
|
|
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
|
|
Date: Fri, 30 Jun 2000 21:57:46 +1000
|
|
To: pgsql-hackers@postgresql.org
|
|
From: Philip Warner <pjw@rhyme.com.au>
|
|
Subject: [HACKERS] Minor buglet in update...from (I think)
|
|
MIME-Version: 1.0
|
|
Content-Type: text/plain; charset="us-ascii"
|
|
X-Mailing-List: pgsql-hackers@postgresql.org
|
|
Precedence: bulk
|
|
Sender: pgsql-hackers-owner@hub.org
|
|
Status: ORr
|
|
|
|
|
|
A minor nasty error I got when trying to improve the query used to disable
|
|
triggers:
|
|
|
|
create table t1(f1 int4, f2 int4);
|
|
create table t2(f1 int4, f2 int4);
|
|
|
|
insert into t1 values(1, 0);
|
|
insert into t1 values(2, 0);
|
|
|
|
insert into t2 values(1, 0);
|
|
|
|
update t1 set f2=count(*) from t2 where t1.f1=1 and t2.f1=t1.f1 ;
|
|
UPDATE 1
|
|
|
|
update t1 set f2=count(*) from t2 where t1.f1=2 and t2.f1=t1.f1 ;
|
|
ERROR: ExecutePlan: (junk) `ctid' is NULL!
|
|
|
|
I would have expected no update to occur since no rows match.
|
|
|
|
|
|
----------------------------------------------------------------
|
|
Philip Warner | __---_____
|
|
Albatross Consulting Pty. Ltd. |----/ - \
|
|
(A.C.N. 008 659 498) | /(@) ______---_
|
|
Tel: (+61) 0500 83 82 81 | _________ \
|
|
Fax: (+61) 0500 83 82 82 | ___________ |
|
|
Http://www.rhyme.com.au | / \|
|
|
| --________--
|
|
PGP key available upon request, | /
|
|
and from pgp5.ai.mit.edu:11371 |/
|
|
|