On 10/6/16, Serge Rielau <se...@rielau.com> wrote: >> On Oct 6, 2016, at 9:01 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> BTW, it also occurs to me that there are going to be good implementation >> reasons for restricting it to be a hard constant, not any sort of >> expression. We are likely to need to be able to insert the value in >> low-level code where general expression evaluation is impractical. >> > Yes, the padding must happen primarily in the getAttr() routines. > Clearly we do not want to evaluate an expression there. > But what speaks against evaluating the expression before we store it? > After all we seem to all agree that this only works if the expression > computes to the same constant all the time. > > If we do not want to store an “untyped” datum straight in pg_attribute as a > BYTEA (my current approach)
Ough. I made a mistake about pg_attribute because I forgot about the pg_attrdef. If we do not merge these tables, the pg_attrdef is the best place to store evaluated expression as a constant the same way defaults are stored in adbin. > we could store the pretty printed version of the constant It is a wrong way. It ruins commands like "ALTER COLUMN ... TYPE ... USING" > and evaluate that when we build the tuple descriptor. > This happens when we load the relation into the relcache. > > Anyway, I’m jumping ahead and it’s perhaps best to let the code speak for > itself once I have the WIP patch ready so we have something concrete to > discuss -- Best regards, Vitaly Burovoy -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers