Re: Fast AT ADD COLUMN with DEFAULTs

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Fast AT ADD COLUMN with DEFAULTs
Дата
Msg-id 22135.1475769672@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Fast AT ADD COLUMN with DEFAULTs  (Serge Rielau <serge@rielau.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: memory leak in e94568ecc10 (pre-reading in external sort)
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: memory leak in e94568ecc10 (pre-reading in external sort)