Re: Fast AT ADD COLUMN with DEFAULTs - Mailing list pgsql-hackers

From Serge Rielau
Subject Re: Fast AT ADD COLUMN with DEFAULTs
Date
Msg-id B6A11E38-3A41-4219-AC02-5F4CC30BCC84@rielau.com
Whole thread Raw
In response to Re: Fast AT ADD COLUMN with DEFAULTs  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fast AT ADD COLUMN with DEFAULTs  (Vitaly Burovoy <vitaly.burovoy@gmail.com>)
List pgsql-hackers
> On Oct 6, 2016, at 9:01 AM, Tom Lane <tgl@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
thepretty 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
havesomething concrete to discuss 

Cheers
Serge





pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: memory leak in e94568ecc10 (pre-reading in external sort)
Next
From: Vitaly Burovoy
Date:
Subject: Re: Fast AT ADD COLUMN with DEFAULTs