| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Cc: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Confusing behavior of create table like |
| Date: | 2020-08-04 22:27:32 |
| Message-ID: | 2465131.1596580052@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> On 2020-08-04 19:36, Konstantin Knizhnik wrote:
>> 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 current specification of serial is a parse-time expansion of integer
> column, sequence, and column default.
Yeah; and note it's actually defined that way in the docs.
I'd certainly concede that serial is a legacy feature now that we have
identity columns. But, by the same token, its value is in backwards
compatibility with old behaviors. Therefore, reimplementing it in a
way that isn't 100% backwards compatible seems like entirely the
wrong thing to do. On similar grounds, I'd be pretty suspicious of
changing LIKE's behaviors around the case.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2020-08-04 22:58:30 | Re: Concurrency bug in amcheck |
| Previous Message | Jehan-Guillaume de Rorthais | 2020-08-04 22:04:53 | Re: [patch] demote |