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

From Tom Lane
Subject Re: Fast AT ADD COLUMN with DEFAULTs
Date
Msg-id 22135.1475769672@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fast AT ADD COLUMN with DEFAULTs  (Serge Rielau <serge@rielau.com>)
Responses Re: Fast AT ADD COLUMN with DEFAULTs  (Serge Rielau <serge@rielau.com>)
Re: Fast AT ADD COLUMN with DEFAULTs  (Vitaly Burovoy <vitaly.burovoy@gmail.com>)
Re: Fast AT ADD COLUMN with DEFAULTs  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
Serge Rielau <serge@rielau.com> writes:
>> On Oct 6, 2016, at 5:25 AM, Vitaly Burovoy <vitaly.burovoy@gmail.com> wrote:
>>> Which makes me think we should call this missing_value or absent_value
>>> so its clear that it is not a "default" it is the value we use for
>>> rows that do not have any value stored for them.

> I like Tom’s “creation default”. Another one could be “initial default”.
> But that, too, can be misread.

Something based on missing_value/absent_value could work for me too.
If we name it something involving "default", that definitely increases
the possibility for confusion with the regular user-settable default.

Also worth thinking about here is that the regular default expression
affects what will be put into future inserted rows, whereas this thing
affects the interpretation of past rows.  So it's really quite a different
animal.  That's kind of leading me away from calling it creation_default.

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: memory leak in e94568ecc10 (pre-reading in external sort)
Next
From: Peter Geoghegan
Date:
Subject: Re: memory leak in e94568ecc10 (pre-reading in external sort)