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/IDENTITY
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 them
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
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
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-04.pdf
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, and
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.
Agreed,
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
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/IDENTITY patch. In particular, it looks to me like we've
been implementing GENERATED ALWAYS AS (expr) according to the rules
that the spec in fact lays
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
10 matches
Mail list logo
