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. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
