> 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) we could store the pretty printed version of the constant 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 Cheers Serge -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
