Re: Confusing behavior of create table like

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

In response to

Responses

Browse pgsql-hackers by date

  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?