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 8E70C144-DC6F-419E-8365-BC9B4F6F231E@rielau.com
Whole thread Raw
In response to Re: Fast AT ADD COLUMN with DEFAULTs  (Vitaly Burovoy <vitaly.burovoy@gmail.com>)
Responses Re: Fast AT ADD COLUMN with DEFAULTs  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
> On Oct 5, 2016, at 5:52 PM, Vitaly Burovoy <vitaly.burovoy@gmail.com> wrote:
>
> On 10/5/16, Serge Rielau <serge@rielau.com> wrote:
>> I want to point out as a minor "extension" that there is no need for the
>> default to be immutable. It is merely required that the default is evaluate
>> at time of ADD COLUMN and then we remember the actual value for the exist
>> default, rather than the parsed expression as we do for the "current"
>> default.
>
> I don't think it will be accepted.
And I wouldn’t expect it to. I had a misunderstanding on what PG did.
Clearly the enhancement must be semantically neutral and be limited to the
cases where that can be asserted.
So my patch will detect that situation and fall back to the original behavior as needed.
> Your patch must be based on a just "master" branch.
> If you haven't seen wiki pages [1], [2] and [3], it is the time to do
> it (and related ones).
>
>> Or should I compose some sort of a design document?
>
> Since Tom Lane, Andres Freund and other people agreed "it does work",
> you may post a patch to a new thread and write a short (but clean
> enough) description with a link to the current thread. Examples can be
> seen by links from the CF[4].
Thanks of rte guidance.
It will take a bit of time to port to community code and complete QA.
I shall return….
Serge Rielau
Salesforce.com




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Our "fallback" atomics implementation doesn't actually work
Next
From: Tom Lane
Date:
Subject: Re: Our "fallback" atomics implementation doesn't actually work