Confusing behavior of create table like - Mailing list pgsql-hackers

From Konstantin Knizhnik
Subject Confusing behavior of create table like
Date
Msg-id 0f7574c7-40cb-6b9c-5f79-c7b57f98ea15@postgrespro.ru
Whole thread Raw
Responses Re: Confusing behavior of create table like
List pgsql-hackers
Postgres provides serial and bigserial column types for which it 
implicitly creates sequence.
As far as this mechanism is somehow hidden from user, it may be 
confusing that table
created with CREATE TABLE LIKE has no associated sequence.

But what is worse, even if experienced user knows that serial types are 
implemented in Postgres by specifying
nextval(seq) default value for this column and default values are copied 
by CREATE TABLE LIKE only if is it explicitly requested (including all),
then two tables will share the same sequence:

create table t1(x serial primary key, val int);
create table t2(like t1 including all);


postgres=# \d+ t1;
                                                Table "public.t1"
  Column |  Type   | Collation | Nullable | Default            | Storage 
| Stats target | Description
--------+---------+-----------+----------+-------------------------------+---------+--------------+-------------
  x      | integer |           | not null | 
nextval('t1_x_seq'::regclass) | plain   |              |
  val    | integer |           | |                               | 
plain   |              |
Indexes:
     "t1_pkey" PRIMARY KEY, btree (x)
Access method: heap

postgres=# \d+ t2;
                                                Table "public.t2"
  Column |  Type   | Collation | Nullable | Default            | Storage 
| Stats target | Description
--------+---------+-----------+----------+-------------------------------+---------+--------------+-------------
  x      | integer |           | not null | 
nextval('t1_x_seq'::regclass) | plain   |              |
  val    | integer |           | |                               | 
plain   |              |
Indexes:
     "t2_pkey" PRIMARY KEY, btree (x)
Access method: heap


Please notice that index is correctly replaced, but sequence - not.
I consider such behavior more like bug than a feature.
And it can be fixed using relatively small patch.

Thoughts?


Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Cache relation sizes?
Next
From: Thomas Munro
Date:
Subject: Re: Comment simplehash/dynahash trade-offs