Skip site navigation (1) Skip section navigation (2)

Re: Type Categories for User-Defined Types

From: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Type Categories for User-Defined Types
Date: 2008-07-30 17:42:24
Message-ID: 011A2FCD-8775-4119-B8B2-A76DF111F652@kineticode.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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


In response to

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2008-07-30 17:55:10
Subject: Re: Type Categories for User-Defined Types
Previous:From: Tom LaneDate: 2008-07-30 17:34:49
Subject: Re: Type Categories for User-Defined Types

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group