Re: future of serial and identity columns

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Vik Fearing <vik(at)postgresfriends(dot)org>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: future of serial and identity columns
Date: 2022-10-07 12:07:34
Message-ID: CABUevEyg62B+ADm1wyy1BsgtDQySc_UWmiwcqnPOANwYaqnhJQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 7, 2022 at 2:03 PM Vik Fearing <vik(at)postgresfriends(dot)org> wrote:

> On 10/4/22 09:41, Peter Eisentraut wrote:
> > In PostgreSQL 10, we added identity columns, as an alternative to serial
> > columns (since 6.something). They mostly work the same. Identity
> > columns are SQL-conforming, have some more features (e.g., overriding
> > clause), and are a bit more robust in schema management. Some of that
> > was described in [0]. AFAICT, there have been no complaints since that
> > identity columns lack features or are somehow a regression over serial
> > columns.
> >
> > But clearly, the syntax "serial" is more handy, and most casual examples
> > use that syntax. So it seems like we are stuck with maintaining these
> > two variants in parallel forever. I was thinking we could nudge this a
> > little by remapping "serial" internally to create an identity column
> > instead. At least then over time, the use of the older serial
> > mechanisms would go away.
> >
> > Note that pg_dump dumps a serial column in pieces (CREATE SEQUENCE +
> > ALTER SEQUENCE ... OWNED BY + ALTER TABLE ... SET DEFAULT). So if we
> > did this, any existing databases would keep their old semantics, and
> > those who really need it can manually create the old semantics as well.
> >
> > Attached is a demo patch how the implementation of this change would
> > look like. This creates a bunch of regression test failures, but
> > AFAICT, those are mainly display differences and some very peculiar test
> > setups that are intentionally examining some edge cases. These would
> > need to be investigated in more detail, of course.
>
> I haven't tested the patch yet, just read it.
>
> Is there any reason to use BY DEFAULT over ALWAYS? I tend to prefer the
> latter.
>

I would assume to maintain backwards compatibility with the semantics of
SERIAL today?

I do also prefer ALWAYS, but that would make it a compatibility break.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2022-10-07 12:10:44 Simplify event trigger support checking functions
Previous Message Vik Fearing 2022-10-07 12:02:52 Re: future of serial and identity columns