Re: identity columns

From: Noah Misch <noah(at)leadboat(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: identity columns
Date: 2017-04-14 05:56:44
Message-ID: 20170414055644.GF2870454@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 06, 2017 at 10:26:16PM -0700, Vitaly Burovoy wrote:
> On 4/6/17, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> > On 4/4/17 22:53, Vitaly Burovoy wrote:
> >> The next nitpickings to the last patch. I try to get places with
> >> lacking of variables' initialization.
> >> All other things seem good for me now. I'll continue to review the
> >> patch while you're fixing the current notes.
> >
> > Committed with your changes (see below) as well as executor fix.
>
> Thank you very much!
>
>
> > As I tried to mention earlier, it is very difficult to implement the IF
> > NOT EXISTS behavior here, because we need to run the commands the create
> > the sequence before we know whether we will need it.
>
> In fact with the function "get_attidentity" it is not so hard. Please,
> find the patch attached.
> I've implement SET GENERATED ... IF NOT EXISTS. It must be placed
> before other SET options but fortunately it conforms with the
> standard.
> Since that form always changes the sequence behind the column, I
> decided to explicitly write "[NO] CACHE" in pg_dump.
>
> As a plus now it is possible to rename the sequence behind the column
> by specifying SEQUENCE NAME in SET GENERATED.
>
> I hope it is still possible to get rid of the "ADD GENERATED" syntax.

[Action required within three days. This is a generic notification.]

The above-described topic is currently a PostgreSQL 10 open item. Peter,
since you committed the patch believed to have created it, you own this open
item. If some other commit is more relevant or if this does not belong as a
v10 open item, please let us know. Otherwise, please observe the policy on
open item ownership[1] and send a status update within three calendar days of
this message. Include a date for your subsequent status update. Testers may
discover new open items at any time, and I want to plan to get them all fixed
well in advance of shipping v10. Consequently, I will appreciate your efforts
toward speedy resolution. Thanks.

[1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-04-14 06:00:55 Re: Rewriting the test of pg_upgrade as a TAP test
Previous Message Noah Misch 2017-04-14 05:53:10 Re: Allowing extended stats on foreign and partitioned tables