From pgsql-hackers-owner+M15878=candle.pha.pa.us=pgman@postgresql.org Mon Nov 26 18:35:28 2001 Return-path: 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 ; 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 ; 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 ; 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 cc: Philip Warner , 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 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: ORr Bruce Momjian 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: 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 ; 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 cc: Philip Warner , 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 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 Status: ORr Bruce Momjian 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: 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 ; 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 ; 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 ; 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 cc: Philip Warner , 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 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Bruce Momjian 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: 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 ; 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 ; 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 ; 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 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 Date: Mon, 26 Nov 2001 19:39:06 -0500 (EST) cc: Philip Warner , 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 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: 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 ; 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 cc: Philip Warner , 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 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 Status: ORr Bruce Momjian 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: 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 ; 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 ; 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 ; 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 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 Date: Mon, 26 Nov 2001 19:58:06 -0500 (EST) cc: Philip Warner , 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 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 ; 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 ; 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 ; 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 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 |/