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
|
Список | 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 по дате отправления: