| From: | Shay Rojansky <roji(at)roji(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Vik Fearing <vik(at)postgresfriends(dot)org>, Amit Langote <amitlangote09(at)gmail(dot)com>, pavel(dot)boev(at)invitae(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #16913: GENERATED AS IDENTITY column nullability is affected by order of column properties |
| Date: | 2021-05-15 15:43:21 |
| Message-ID: | CADT4RqCQctfmr1rd9u72HEkw-PN9OQMSw=4UZM_4cA22viZ9fw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
> I'll go adjust that
Thanks Tom.
> so the spec does clearly say that both alternatives force NOT NULL.
For what it's worth, it's odd to disallow nullable columns which are also
GENERATED BY DEFAULT AS IDENTITY - unless I'm missing something, it seems
like quite an artificial restriction for a legitimate scenario. After all,
we can do:
CREATE SEQUENCE foo_seq AS integer;
CREATE TABLE foo (
bar INTEGER NULL DEFAULT nextval('foo_seq')
);
... which is logically very similar, and definitely seems useful. Would it
make sense to allow nullable GENERATED BY DEFAULT AS IDENTITY as a PG
extension?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shay Rojansky | 2021-05-15 15:54:32 | Re: BUG #16913: GENERATED AS IDENTITY column nullability is affected by order of column properties |
| Previous Message | David G. Johnston | 2021-05-15 15:15:05 | Re: BUG #17007: server process (PID XXXX) was terminated by signal 11: Segmentation fault |