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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
