From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Confusing behavior of create table like |
Date: | 2020-08-04 16:53:20 |
Message-ID: | CA+TgmoaBD7Y6PiUbhrBcJpYG7yZ7Tm37guSa-SxDYO_gVd4M3g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 3, 2020 at 12:35 PM Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> On 2020-08-03 14:58, Konstantin Knizhnik wrote:
> > May be generated and identity columns are good things. I have nothing
> > against them.
> > But what preventing us from providing the similar behavior for
> > serial/bigseries types?
>
> In my mind, serial/bigserial is deprecated and it's not worth spending
> effort on patching them up.
>
> One thing we could do is change serial/bigserial to expand to identity
> column definitions instead of the current behavior.
I'm not really convinced that's a good idea. There's probably a lot of
people (me included) who are used to the way serial and bigserial work
and wouldn't necessarily be happy about a change. Plus, aren't the
generated columns still depending on an underlying sequence anyway?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2020-08-04 16:56:25 | Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY |
Previous Message | Robert Haas | 2020-08-04 16:50:29 | Re: Can a background worker exist without shared memory access for EXEC_BACKEND cases? |