| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Feike Steenbergen <feikesteenbergen(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #15198: nextval() accepts tables/indexes when adding a default to a column |
| Date: | 2018-05-17 16:36:31 |
| Message-ID: | 20180517163631.cjphtsklcwhjdf6w@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 2018-May-17, Andres Freund wrote:
> These alternatives seem like they're not an improvement. I don't think
> it's worth doing anything here.
I agree.
If our nextval was less opaque, it'd be worth doing better. I mean
something like
CREATE TABLE tt (
col integer DEFAULT someseq.nextval
...
)
which I think has been proposed over the years (and ultimately rejected;
and even if implemented[1], this would not prevent our current syntax
from being accepted). But we've stuck with the function-call syntax for
better or worse. Let's live with it.
[1] That syntax currently gets this funny error:
alvherre=# create table ff (a int default seq.nextval);
ERROR: missing FROM-clause entry for table "seq"
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2018-05-17 20:11:42 | BUG #15205: ERROR: table row type and query-specified row type do not match |
| Previous Message | Andres Freund | 2018-05-17 16:21:19 | Re: BUG #15198: nextval() accepts tables/indexes when adding a default to a column |