Re: [HACKERS] Behavior of GENERATED columns per SQL2003

2007-05-14 Thread Bruce Momjian
URL added to TODO item. Patch rejected for 8.3. --- Tom Lane wrote: > I've been studying the SQL spec in a bit more detail and I'm suddenly > thinking that we've got the behavior all wrong in the current > GENERATED/IDENTIT

Re: [HACKERS] Behavior of GENERATED columns per SQL2003

2007-05-11 Thread Richard Huxton
Tom Lane wrote: "Simon Riggs" <[EMAIL PROTECTED]> writes: On Thu, 2007-05-10 at 10:11 -0400, Tom Lane wrote: As for GENERATED ALWAYS AS (expr), now that we understand that it's not supposed to define a virtual column, what's the point? We do need virtual columns, whether the spec requires th

Re: [HACKERS] Behavior of GENERATED columns per SQL2003

2007-05-10 Thread Tom Lane
"Simon Riggs" <[EMAIL PROTECTED]> writes: > On Thu, 2007-05-10 at 10:11 -0400, Tom Lane wrote: >> As for GENERATED ALWAYS AS (expr), now that we understand that it's not >> supposed to define a virtual column, what's the point? > We do need virtual columns, whether the spec requires them or not.

Re: [HACKERS] Behavior of GENERATED columns per SQL2003

2007-05-10 Thread Simon Riggs
On Thu, 2007-05-10 at 10:11 -0400, Tom Lane wrote: > As for GENERATED ALWAYS AS (expr), now that we understand that it's not > supposed to define a virtual column, what's the point? You can get the > same behavior with a trivial BEFORE INSERT/UPDATE trigger that > recomputes the derived value, an

Re: [HACKERS] Behavior of GENERATED columns per SQL2003

2007-05-10 Thread Tom Lane
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes: > Tom Lane írta: >> This means that GENERATED BY DEFAULT AS IDENTITY is not at all >> equivalent to our historical behavior for SERIAL columns and hence we >> cannot merge the two cases. > Yes, they are equivalent if you read 5IWD2-02-Foundation-2006-

Re: [HACKERS] Behavior of GENERATED columns per SQL2003

2007-05-10 Thread Zoltan Boszormenyi
Zoltan Boszormenyi írta: The quoted SIGMOD paper mentioned that specifying a value for a generated column should raise an error in INSERT but this behaviour is not mentioned by the standard. I found it now, I haven't read hard enough before. SQL:2003, section 14.8, syntax rules: 10) If CTTVC

Re: [HACKERS] Behavior of GENERATED columns per SQL2003

2007-05-10 Thread Zoltan Boszormenyi
Tom Lane írta: After some more study of the SQL spec, the distinction between GENERATED ALWAYS AS IDENTITY and GENERATED BY DEFAULT AS IDENTITY is not what I thought it was. * As far as I can find from the spec, there is *no* difference between the two cases for INSERT commands. The rule is tha

Re: [HACKERS] Behavior of GENERATED columns per SQL2003

2007-05-09 Thread Tom Lane
After some more study of the SQL spec, the distinction between GENERATED ALWAYS AS IDENTITY and GENERATED BY DEFAULT AS IDENTITY is not what I thought it was. * As far as I can find from the spec, there is *no* difference between the two cases for INSERT commands. The rule is that you ignore any

Re: [HACKERS] Behavior of GENERATED columns per SQL2003

2007-05-07 Thread David Fuhry
Oracle 10g, MySQL 5, and SQL Server 2005 don't appear to support the syntax. The SQL:2003 SIGMOD paper [1] indicates pretty clearly that their intention is for the values of generated columns to be stored on disk: "... commonly used expressions are evaluated once and their results stored for