Re: Confusing behavior of create table like

From: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Confusing behavior of create table like
Date: 2020-08-04 17:36:13
Message-ID: 79df00cd-aaef-10ab-eec0-5300306998d2@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 04.08.2020 19:53, Robert Haas wrote:
> 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?
>
Yes, generated columns are also using implicitly generated sequences.
So them are  very similar with SERIAL/BIGSERIAL columns. This actually
make we wonder why we can not handle them in the same way in
CREATE TABLE LIKE.
The only difference is that it is not possible to explicitly specify
sequence for generated column.
And it certainly makes there  handling in CREATE TABLE LIKE less
contradictory.

I think that many people are using serial/bigserial types in their
database schemas and will continue to use them.
I do not expect that any of them will be upset of behavior of handling
this columns in CREATE TABLE LIKE ... INCLUDING ALL will be changed.
Mostly because very few people are using this construction. But if
someone wants to use it, then most likely he will be confused
(I have not imagine this problem myself - it was motivated by question
in one of Postgres forums where current behavior was interpreted as bug).
So I do not think that "backward compatibility" is actually good in this
case and that somebody can suffer from changing it.

I do not insist - as I already told, I do not think that much people are
using CREATE TABLE LIKE, so it should not be a big problem.
But if there is some will to change current behavior, then I can send
more correct version of the patch and may be submit it to commitfest.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2020-08-04 17:44:08 Re: LSM tree for Postgres
Previous Message Andrey M. Borodin 2020-08-04 17:28:22 Re: Yet another fast GiST build (typo)