"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> On Jul 29, 2008, at 16:45, 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.
>>> Nice! Does it also allow all of the casts to and from text to
>>> implicitly work, e.g,
>>
>> No, but we could think about that. Do we really want that to work for
>> any member of the string category? It seems a bit overly broad to me
>> ...
> I was thinking about other text-style types, like UUID and UPC, and
> was thinking probably not, at least for them. OTOH, some strings
> should work that way, like citext or enums, the difference being that,
> in most contexts, they can be treated as plain text, since they're
> usually thought of that way. Or so it seems to me. Might there be a
> way to create that distinction?
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. 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.
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.
[ 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.
Comments anyone?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
