Re: Fast AT ADD COLUMN with DEFAULTs - Mailing list pgsql-hackers
On Wed, Oct 5, 2016 at 4:19 PM, Vitaly Burovoy <vitaly.burovoy@gmail.com> wrote:
On 10/5/16, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> Need a better name for the concept, since evidently this name isn't
>> conveying the idea.
>
> Maybe "creation default" would work better? Point being it's the
> default value at the time of column creation.
Hmm... Personaly for me the original topic name is good enough.
I think at issue is with the term “exist default” rather than the feature/topic name (?)
But what I discover for myself is that we have pg_attrdef separately
from the pg_attribute. Why?
Is it time to join them? For not presented defaults it would be only
one bit per row(if we avoid "adsrc" as it is recommended), but for a
separate table it is 11 columns with two indexes now...
In terms of footprint we may be able to remove pg_attrdef.
I would consider that orthogonal to the proposed feature though.
The internal representation of defaults in the tuple descriptor still needs to be a map of sorts.
To comment on Pantelis SQL Server Reference:
Other vendors such as Oracle and DB2 also support this feature.
The listed restriction made me loop back to Vitaly’s original serial example:
ALTER TABLE t ADD COLUMN c2 serial;
and rethink Tom’s struct restriction to constants.
In PG the proposed feature would also have to be limited to immutable(?) default expressions to comply with existing behavior, which matches SQL Servers.
My current patch does not restrict that and thusly falsely "fills in" the same value for all rows.
Cheers
Serge Rielau
Salesforce.com
pgsql-hackers by date: