From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Feike Steenbergen <feikesteenbergen(at)gmail(dot)com> |
Cc: | 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:21:19 |
Message-ID: | 20180517162119.qslb3bkftvomqt5e@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi,
On 2018-05-17 08:41:53 +0200, Feike Steenbergen wrote:
> On 16 May 2018 at 16:20, Peter Eisentraut
> <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>
> > In this case, they are putting the erroneous call into a column default,
> > so the difference ends up being getting the error at setup time versus
> > at run time, which is a difference of significance.
>
> Yes, I'm not particularly concerned with nextval taking a regclass as
> an argument, and
> therefore raising this error, but I'd rather have this error at DDL
> time than at DML time.
>
> I don't know how hard it would be to implement, but say, calling
> currval(regclass) when
> a default is defined should already throw this error at DDL time.
>
> Or, when registering the default in the catalog, we verify that it is
> actually a sequence:
These alternatives seem like they're not an improvement. I don't think
it's worth doing anything here.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-05-17 16:36:31 | Re: BUG #15198: nextval() accepts tables/indexes when adding a default to a column |
Previous Message | reader 1001 | 2018-05-17 16:17:59 | Re: Abnormal JSON query performance |