Re: On hardcoded type aliases and typmod for user types

Martijn van Oosterhout <kleptog@svana.org> writes:
> 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.

That strikes me as an unnecessary reduction in flexibility.  As long as
we make the hardwired type names translate to qualified names (same as
they do now) we don't have to assume any such thing.

(What I might actually favor doing that for is operators, because the
schema-qualified syntax for operators is so gross.  But I don't see a
need for it for type names.)

>> 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.

Right.  I think thatpg_catalog.varchar(n)
is reasonable and should be accepted, but I'm fine with decreeing thatcharacter varying(n)
will always be special non-schema-qualified syntax (which the grammar
will in fact translate into the former).

The point about character sets is a bit distressing; here we are
designing a new general-purpose mechanism and we can already see
cases it doesn't handle.  Can we fix that?
        regards, tom lane