Re: On hardcoded type aliases and typmod for user types

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: On hardcoded type aliases and typmod for user types
Дата
Msg-id 2009.1125501064@sss.pgh.pa.us
обсуждение исходный текст
Ответ на On hardcoded type aliases and typmod for user types  (Martijn van Oosterhout <kleptog@svana.org>)
Ответы Re: On hardcoded type aliases and typmod for user types  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-hackers
Martijn van Oosterhout <kleptog@svana.org> writes:
> My question is, should users be able to create types schema.int4 and
> schema.integer simultaneously. Currently it allows you but it's not
> handled very well (\dT doesn't list both). Should this be allowed?
> Should aliasing for DEC and DECIMAL -> NUMERIC be done for
> user-defined types?

IMHO, ideally the aliasing should *only* apply to the built-in types.
The current hack only approximates this (IIRC, the translation happens
for any unqualified type name, independently of one's search path).

One possible approach is to remove the aliasing translation from the
grammar altogether, and add a notion of "alias" entries in pg_type that
would be found through normal lookup and then replaced by the underlying
type by parse analysis rather than by the grammar.  We could not do this
in the existing system because of the need to handle typmods for some of
the aliases ... but maybe it would work given generalized typmod
support.  There are still a few special cases though, like CHARACTER
VARYING, which seems like it more or less has to be wired into the
grammar.

BTW, the proposed refactoring sounds messier to me than does decreeing
type and function names equivalent ...
        regards, tom lane


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

Предыдущее
От: Devrim GUNDUZ
Дата:
Сообщение: Re: problems installing pgsql
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: Pre-allocated free space for row