Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.
Дата
Msg-id 15947.1485177292@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Assignment of valid collation for SET operations onqueries with UNKNOWN types.  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
Michael Paquier <michael.paquier@gmail.com> writes:
> One thing though: even with this patch, it is still possible to define
> a domain with unknown as underlying type and have a table grab it:
> create domain name as unknown;
> create table foo_name (a name);
> I think that this case should be restricted as well, and pg_upgrade
> had better complain with a lookup at typbasetype in pg_type.

Yeah, this is the sort of corner case that I think we ought to plug
by turning "unknown" into a true pseudotype.  DefineDomain already
has a defense against that:

regression=# create domain d2 as anyelement;
ERROR:  "anyelement" is not a valid base type for a domain
regression=# \errverbose 
ERROR:  42804: "anyelement" is not a valid base type for a domain
LOCATION:  DefineDomain, typecmds.c:812

Some prodding indicates that the PLs are not uniformly preventing
making functions with unknown input or result type, either.
That's another case that would be less likely to get missed if it
were a true pseudotype.

However, I think that's all material for a separate patch.  This
patch is just concerned with what the main parser should do with
"unknown", not with what utility commands should do with it.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] Checksums by default?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.