Re: [GENERAL] SQL spec/implementation question: UPDATE

2007-10-23 Thread Nis Jørgensen
Albe Laurenz skrev: > Tom Lane wrote: >>> I don't have handy a spec guide. Does this mean that MySQL >>> is indeed showing incorrect behavior? >> I think this is really outside the spec. > [...] >> There is not anything I can see addressing whether an >> "update" should or should not be considere

Re: [GENERAL] SQL spec/implementation question: UPDATE

2007-10-22 Thread Erik Jones
On Oct 22, 2007, at 11:01 AM, Alan Hodgson wrote: On Sunday 21 October 2007, Kevin Hunter <[EMAIL PROTECTED]> wrote: Heh. And as Tom points out downthread, that "shortcut" probably doesn't gain anything in the long run. Considering how expensive updates are in PostgreSQL, I suspect that

Re: [GENERAL] SQL spec/implementation question: UPDATE

2007-10-22 Thread Alan Hodgson
On Sunday 21 October 2007, Kevin Hunter <[EMAIL PROTECTED]> wrote: > Heh. And as Tom points out downthread, that "shortcut" probably doesn't > gain anything in the long run. Considering how expensive updates are in PostgreSQL, I suspect that isn't true. However, the current behaviour does seem

Re: [GENERAL] SQL spec/implementation question: UPDATE

2007-10-22 Thread Albe Laurenz
Tom Lane wrote: >> I don't have handy a spec guide. Does this mean that MySQL >> is indeed showing incorrect behavior? > > I think this is really outside the spec. [...] > There is not anything I can see addressing whether an > "update" should or should not be considered to occur if a > target c

Re: [GENERAL] SQL spec/implementation question: UPDATE

2007-10-21 Thread Tom Lane
Kevin Hunter <[EMAIL PROTECTED]> writes: > I don't have handy a spec guide. Does this mean that MySQL is indeed > showing incorrect behavior? I think this is really outside the spec. The relevant sections of SQL92 seem to be in 13.10 : ::= UPDATE SET

Re: [GENERAL] SQL spec/implementation question: UPDATE

2007-10-21 Thread Kevin Hunter
At 11:33p -0400 on 21 Oct 2007, Ron Johnson wrote: > Not to bash MySQL (much...) but ISTM that this is another example of > MySQL playing fast and loose with SQL. I don't have handy a spec guide. Does this mean that MySQL is indeed showing incorrect behavior? I like what's been said upthread: T

Re: [GENERAL] SQL spec/implementation question: UPDATE

2007-10-21 Thread Kevin Hunter
At 6:52p -0400 on 21 Oct 2007, Tom Lane wrote: > andy <[EMAIL PROTECTED]> writes: >> I think your comparing apples and oranges. I'll bet that mysql is >> taking a shortcut and testing the value before updating it. > >> The update is probably more close to: >> update test set name = 'kevin' where

Re: [GENERAL] SQL spec/implementation question: UPDATE

2007-10-21 Thread Kevin Hunter
At 6:00p -0400 on 21 Oct 2007, andy wrote: > I think your comparing apples and oranges. That's why I ask the list! To learn when I'm doing that. ;-) > I'll bet that mysql is > taking a shortcut and testing the value before updating it. Heh. And as Tom points out downthread, that "shortcut" p

Re: [GENERAL] SQL spec/implementation question: UPDATE

2007-10-21 Thread Ron Johnson
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/21/07 17:52, Tom Lane wrote: > andy <[EMAIL PROTECTED]> writes: >> I think your comparing apples and oranges. I'll bet that mysql is >> taking a shortcut and testing the value before updating it. > >> The update is probably more close to: >> u

Re: [GENERAL] SQL spec/implementation question: UPDATE

2007-10-21 Thread Tom Lane
andy <[EMAIL PROTECTED]> writes: > I think your comparing apples and oranges. I'll bet that mysql is > taking a shortcut and testing the value before updating it. > The update is probably more close to: > update test set name = 'kevin' where passion = 'soccer' and name <> 'kevin'; Yeah, that se

Re: [GENERAL] SQL spec/implementation question: UPDATE

2007-10-21 Thread andy
Kevin Hunter wrote: Hullo list, A perhaps esoteric question: Short version: What do the specs say (if anything) about returning information from UPDATE commands? Or about handling update request that don't effectively do anything? Longer version: CREATE TABLE test ( id SERIAL NOT NUL