Gregory Stark <[EMAIL PROTECTED]> writes:
> I had a different thought when you posted the original prompt earlier. Instead
> of a static list of type categories we could re-use type oids. So if you
> belong to a type category you store the oid of the preferred type of that
> category in typcategory.
The problem with that is it assumes that each category has one and only
one preferred type. This isn't the case in NUMERIC_TYPE for instance.
What is actually going on in NUMERIC_TYPE is that the OID and OID-alias
types form a sub-category; but you have to look at the set of available
implicit casts to realize that. We could maybe get away with one
preferred type per category if we wanted to invent an explicit
representation of sub-categories, but that seems too complicated.
In any case it's not clear to me that the flexibility to have more than
one preferred type might not be helpful in other, less clearly
structured categories.
> I can't help thinking from the list above that there's nothing special about
> datetime, geometric, and network data types that some user defined set of
> types wouldn't necessarily want to define.
Well, that's why the set of categories needs to be extensible. I agree
that some of the existing categories aren't really pulling their weight:
unless you have enough implicit casts within the category to cause
ambiguity, you don't really need preferred types and hence not your own
category.
For the moment I'm just trying to model the behavior of the existing
functions exactly; but once the catalog infrastructure is in, we could
revisit some of those old decisions and try to eliminate useless
categories. In particular I'm thinking that the historical behavior of
treating all user-defined types as preferred might be backwards.
> I do agree that having SQL commands to create new type categories, even a new
> catalog table is overkill, but not because we wouldn't want to create new
> ones. Just because there isn't really any other meta data we want to store
> about type categories. Aside from the preferred type and the members there
> isn't anything more to say about them.
Agreed.
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
