Re: BUG #15198: nextval() accepts tables/indexes when adding a default to a column
От | Tom Lane |
---|---|
Тема | Re: BUG #15198: nextval() accepts tables/indexes when adding a default to a column |
Дата | |
Msg-id | 1817.1526480079@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #15198: nextval() accepts tables/indexes when adding adefault to a column (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: BUG #15198: nextval() accepts tables/indexes when adding adefault to a column
|
Список | 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 по дате отправления: