Re: Behavior of GENERATED columns per SQL2003

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: "Zoltan Boszormenyi" <zb(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Behavior of GENERATED columns per SQL2003
Date: 2007-05-11 02:31:30
Message-ID: 9988.1178850690@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Simon Riggs" <simon(at)2ndquadrant(dot)com> 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, they seem more useful than what the spec's got in mind. You can
fake a virtual column using a view, but it's a whole lot more painful
than faking a GENERATED column using a trigger (at least if you wish the
view to be updatable).

> ISTM that we should interpret this as a requirement for a virtual
> column. We can always move from that to a stored column if the spec
> becomes more specific, though it would be harder to move the other way.

If you're suggesting commandeering the spec's GENERATED ALWAYS syntax
to represent virtual columns, when the committee has made it clear that
that's not what they intend, I say that's sheer folly. What will you do
when they tweak the spec to the point where a virtual column clearly
doesn't satisfy it? If we want a nonstandard feature we should use a
nonstandard syntax for it.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Huxton 2007-05-11 07:32:56 Re: Behavior of GENERATED columns per SQL2003
Previous Message Simon Riggs 2007-05-10 21:14:24 Re: Feature lists for 8.3 and 8.4