From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | feikesteenbergen(at)gmail(dot)com, 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-16 14:14:39 |
Message-ID: | 1817.1526480079@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> On 5/16/18 05:29, PG Bug reporting form wrote:
>> ERROR: 42809: "demo" is not a sequence
> You are right that this is not optimal behavior. I'm not sure if it's
> worth fixing, however. (Introduce a regsequence type to use in place of
> regclass?)
That's about what we'd have to do, and it seems like far more
infrastructure than the problem is worth. All you're accomplishing
is to emit the same error at a different time, and for that you need
a named, documented data type.
Furthermore, there are plenty of other places with a similar claim
to trouble, but I can't see inventing different variants of regclass
to enforce all the different restrictions you could wish for:
* pg_index_has_property could wish for a regindex type, perhaps
(and brin_summarize_new_values could wish for a restriction to
BRIN indexes, or gin_clean_pending_list to GIN indexes)
* pg_relation_filenode could wish for a restriction to relation
kinds that have storage
* pg_relation_is_publishable doubtless has some other relkind
restriction
* I didn't even check functions that currently take OID rather
than regclass
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2018-05-16 14:20:19 | Re: BUG #15198: nextval() accepts tables/indexes when adding a default to a column |
Previous Message | David G. Johnston | 2018-05-16 14:14:36 | Re: BUG #15198: nextval() accepts tables/indexes when adding a default to a column |