Re: On hardcoded type aliases and typmod for user types

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: On hardcoded type aliases and typmod for user types
Date: 2005-08-31 20:43:29
Message-ID: 20050831204312.GE5489@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)svana(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2005-08-31 21:07:04 Re: Pre-allocated free space for row
Previous Message Tony Caduto 2005-08-31 20:41:03 Re: 8.1 and syntax checking at create time