Re: On hardcoded type aliases and typmod for user types

Поиск
Список
Период
Сортировка
От Martijn van Oosterhout
Тема Re: On hardcoded type aliases and typmod for user types
Дата
Msg-id 20050831204312.GE5489@svana.org
обсуждение исходный текст
Ответ на Re: On hardcoded type aliases and typmod for user types  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: On hardcoded type aliases and typmod for user types  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Aug 31, 2005 at 02:25:54PM -0400, Tom Lane wrote:
> I still like the idea of pushing the aliasing out of the grammar,
> though.  Come to think of it, we could probably even handle the
> multiple-word stuff that way: let the grammar convert CHARACTER VARYING
> to "character varying" and have an alias with that name in the catalog.

Currently, a user-defined type, function, table etc is one IDENT, I
don't see any point in changing that. The standard wants "character
varying" and we can support that but we don't need to extend that to
user-defined types. If people really want that they can quote it.
Besides, the character stuff is somewhat special as it has the
"character set" stuff so will need special grammer anyway.

> One thing you'd need to look at is that format_type is aware of the
> special properties of the alias names: at present they never need to be
> schema-qualified, but this would no longer be certainly the case with
> the aliasing approach.  A possible answer is for format_type to work by
> replacing (say) INT4OID with the OID of the alias type that has the
> desired spelling, and then use the same TypeIsVisible test as is applied
> to any user type.  Another thing that is involved there is not
> double-quoting the generated names ... we don't want it to emit
> "character varying" but the user-type path would do that.

I was thinking actually of setting the type searching code to search
pg_catalog before the normal search_path. The types being hardwired
into the grammer essentially implied this so I thought I would avoid
surprises.

This ofcourse would mean that all built-in types would automatically
override user-defined ones, which actually sucks if PostgreSQL keeps
including more types by default. OTOH, then types in pg_catalog never
need to be qualified, making it easy for format_type.

Now i think about it it may not be a good idea, for all its benefits.
Perhaps only doing it for multiword types. Damn special casing.
>
> Hmm... actually there's a bit of an issue here, which is that it's not
> clear whether schema qualification makes sense for the multi-word type
> names.  For instance
>     pg_catalog.character varying

It doesn't work. The current grammer, even now, treats anything schema
qualified as non-special. You can't schema qualify char(4) even if you
want to. Incidently, these typmod changes for user types would make
this work as a side-effect.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

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

Предыдущее
От: Tony Caduto
Дата:
Сообщение: Re: 8.1 and syntax checking at create time
Следующее
От: Tom Lane
Дата:
Сообщение: Re: 8.1 and syntax checking at create time