From: | "Lon Varscsak" <varscsak(at)smarthealth(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | depesz(at)depesz(dot)com, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #4220: delete statement deleted too many rows |
Date: | 2008-06-04 20:58:19 |
Message-ID: | 84cfc0470806041358g4a692c5ata13348d29b9ef58d@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Wow, I want it to violate the spec so I can get my rows back! :)
I understand the problem and why it did what it did now though.
Thanks for your help,
Lon
On Wed, Jun 4, 2008 at 1:08 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> hubert depesz lubaczewski <depesz(at)depesz(dot)com> writes:
> > On Wed, Jun 04, 2008 at 06:46:42PM +0000, Lon Varscsak wrote:
> >> delete from customer_transactions_detail where transaction_id in (select
> >> transaction_id from test);
> >> The transaction_id column does NOT exist in the temporary table named
> >> 'test'). I would think this would just result in an error, instead it
> >> delete all rows in the customer_transactions_detail table.
>
> > i wrote about it in more details in here:
> > http://www.depesz.com/index.php/2007/09/06/postgresql-gotchas/
>
> This isn't a "postgres gotcha", it's a "SQL standard gotcha". Any DBMS
> that fails to execute the query exactly that way is violating the spec.
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-06-04 21:14:25 | Re: BUG #4219: fseeko test failure in configure script |
Previous Message | Nathan Reed | 2008-06-04 20:38:00 | Re: BUG #4219: fseeko test failure in configure script |