Re: On hardcoded type aliases and typmod for user types

Martijn van Oosterhout <kleptog@svana.org> writes:
> On Wed, Aug 31, 2005 at 11:11:04AM -0400, Tom Lane wrote:
>> 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.

> Yeah, I was thinking about alias entries. I was thinking that domains
> might already do a lot of the work. But then it's not really aliasing
> anymore.

Right, a domain isn't quite the same thing.  But you could probably use
domains temporarily for prototyping it.

One reason that I think a domain isn't the same thing is that I believe
domains don't have typmods.  Although you could imagine a domain passing
a typmod down to its base type, that's not what the spec expects AFAICS.
You're supposed to writecreate domain mytype as varchar(4);
There's nothing likecreate domain mytype(n) as varchar(n);
in the spec (and no I don't really wish to invent it...)

> Though maybe the point is that we can take the easy way and implement
> the slightly more difficult if it turns out the be necessary.

That seems fair to me.  Now that we have knowledge in the archives about
how to do it the hard way if needed, we can take the easy way until we
run into an actual need for the hard way.

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.

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.

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 instancepg_catalog.character varying
seems both ugly and syntactically ambiguous.  So maybe we need to stick
to the present solution for the multi-word type names: they are expanded
by the grammar to pre-qualified names, and so you cannot have a user
type selected by such a name, and format_type keeps its current special
case approach to generating them.
        regards, tom lane