Re: Type Categories for User-Defined Types

On Jul 30, 2008, at 10:34, Tom Lane wrote:

>>> [ move preferred-type info into the system catalogs ]
>
> I've committed changes along this line. Please look at CVS HEAD and
> re-evaluate which alias functions/operators you still really need.

Okay, I'll hunt down some tuits today to hack on that.

> UUID and so on aren't considered part of the string category, and
> shouldn't be IMHO ... any type that has semantics significantly
> different from "arbitrary string of text" doesn't belong.

Yes, that was essentially my point. "arbitrary string of text" types
are probably fairly rare, since one can just use text or citext or
varchar.

> At the
> same time I'm not entirely sure that we want the I/O conversions
> to work for everything in the category. As of CVS HEAD, what we've
> got in string category by default are
>
> template1=# select oid::regtype, typtype, typispreferred from
> pg_type where typcategory = 'S';
> oid | typtype | typispreferred
> -----------------------------------+---------+----------------
> "char" | b | f
> name | b | f
> text | b | t
> character | b | f
> character varying | b | f
> information_schema.character_data | d | f
> information_schema.sql_identifier | d | f
> (7 rows)
>
> and you have to remember that *any* domain created over a string type
> will also be considered to be of string category.

Right, that all makes sense.

> The behavior that's hard-wired into parse_coerce.c at the moment
> is that only text, varchar, bpchar can be sources or targets of
> I/O conversions. While opening it up to citext sounds reasonable,
> I'm a lot less sure about domains.

So who might we open it up so that citext can take advantage of it?
I'd love to get rid of all these ugly cast functions I've been writing.

> [ pokes at it ... ] Oh, I hadn't realized this: find_coercion_pathway
> is looking at types that it's already smashed to base types, so
> actually you can get an I/O conversion for a domain over one of these
> types already!
>
> regression=# create domain d2 as varchar(2);
> CREATE DOMAIN
> regression=# select 123::int4::d2;
> d2
> ----
> 12
> (1 row)
>
> So maybe the domain issue isn't so important.

What about enums?

Best,

David