Re: Fast AT ADD COLUMN with DEFAULTs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Serge Rielau <serge(at)rielau(dot)com>
Cc: Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fast AT ADD COLUMN with DEFAULTs
Date: 2016-10-06 16:01:12
Message-ID: 22135.1475769672@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Serge Rielau <serge(at)rielau(dot)com> writes:
>> On Oct 6, 2016, at 5:25 AM, Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)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 Toms 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2016-10-06 16:03:25 Re: memory leak in e94568ecc10 (pre-reading in external sort)
Previous Message Peter Geoghegan 2016-10-06 15:44:15 Re: memory leak in e94568ecc10 (pre-reading in external sort)