Alvaro Herrera írta:
> Excerpts from Boszormenyi Zoltan's message of lun ago 16 14:45:07 -0400 2010:
>
>> Matthew Wilson írta:
>>
>
>
>>> I don't care if the code is rearranged so that c is replaced with an
>>> inline definition during compilation. I'm not concerned about
>>> efficiency here. I just don't want to have to redefine it manually over
>>> and over again, because I know that as I update how c is defined, I'll
>>> forget to update it everywhere.
>>>
>>> Maybe sql needs a preprocessing macro language like C.
>>>
>>>
>> Or maybe we can dust off my GENERATED column patch
>> I posted here in 2006. :-)
>>
>
> Hmm, that seems entirely unrelated ...
>
What makes you think so? A generated column would put
the work into INSERT and UPDATE statements, SELECTs
would be faster and this way re-typing the same expression
would be avoided. The generated column's definition is defined
at one central place, with the type modifier on such a column in
CREATE or ALTER TABLE , so the problem of the OP
would be also solved.
There was only one drawback, as Tom Lane pointed out a while back,
but this was explicitely covered by the SQL standard at the time,
it said that before triggers cannot look at the content of the generated
columns.
And with HOT and no indexes on the generated column, most
of the bloat would also be avoided that comes from the extra
internal UPDATE that such a column would introduce.