Re: BUG #15198: nextval() accepts tables/indexes when adding a default to a column - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #15198: nextval() accepts tables/indexes when adding a default to a column
Date
Msg-id 1817.1526480079@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #15198: nextval() accepts tables/indexes when adding adefault to a column  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: BUG #15198: nextval() accepts tables/indexes when adding adefault to a column
List pgsql-bugs
Peter Eisentraut <peter.eisentraut@2ndquadrant.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


pgsql-bugs by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: BUG #15198: nextval() accepts tables/indexes when adding adefault to a column
Next
From: Peter Eisentraut
Date:
Subject: Re: BUG #15198: nextval() accepts tables/indexes when adding adefault to a column