On 10/5/16, Serge Rielau <se...@rielau.com> wrote: >On Wed, Oct 5, 2016 at 4:19 PM, Vitaly Burovoy <vitaly.buro...@gmail.com> >wrote: >> 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.
It was a question mostly to the community rather than to you. > 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. I'm sorry, the correct example with "now" should be: ALTER TABLE t ADD COLUMN c1 timestamptz NOT NULL DEFAULT 'now'::text::timestamptz; I wanted to show that for non-immutable (even stable) expression as a default one each time selected old tuples gives different result. But your implementation evaluates it before saving as a "pre-add-column" default and it breakes the current behavior in a different way. > 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. If you change the current behavior (just making it "faster") you should save the current behavior. The best case is to determine whether it is possible to do a "fast" change and fill the "pre-add-column" default parameter or leave the current "long" behavior. I assure it is often enough to add columns with a default value which fills the current rows by non-static values. One of them is adding a serial column (which is a macros for "CREATE SEQUENCE+SET NULL+SET DEFAULT nextval(just_created_sequence_relation)"), others are "uuid_generate_vX(...)" and "random()" On 10/5/16, Serge Rielau <se...@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. On 10/5/16, Serge Rielau <se...@rielau.com> wrote: > Thanks. > This would be my first contribution. > I take it I would post a patch based on a recent PG 9.6 master for review? 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]. Nevertheless it is important to honor all thoughts mentioned here because if your patch breaks the current behavior (with no significant reason) it is senseless (even if it matches the behavior of other RDBMS) and will not be committed. Of cource, feel free to ask. [1] https://wiki.postgresql.org/wiki/So,_you_want_to_be_a_developer%3F [2] https://wiki.postgresql.org/wiki/Developer_FAQ [3] https://wiki.postgresql.org/wiki/Submitting_a_Patch [4] https://commitfest.postgresql.org/11/ -- Best regards, Vitaly Burovoy -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
