On Jul 29, 2008, at 13:12, Tom Lane wrote:
Damn, I didn't even notice that! Can that be fixed?
Given the present infrastructure I think the only way would be with
two more alias operators, text||citext and citext||text. But that way
madness lies.
I suppose, then, that you're saying that there are lots of other
functions for which this sort of thing would need to be done? Because
two more aliases for this one operator is no big deal, AFAIC.
It kinda sounds that way, yeah. What happens with DOMAINs, BTW? Do
they need to write hacky functions like the above, or are they aware
of their types because of the types from which they inherit?
Domains are treated as their base types in general. Elein has been
complaining about that for years ;-) ... but I think improving it
is unrelated to this issue.
I see.
After a quick look to verify my recollection: the only two things
that the system does with type categories are
extern CATEGORY TypeCategory(Oid type);
Returns the category a type belongs to.
extern bool IsPreferredType(CATEGORY category, Oid type);
Detects whether a type is a preferred type in its category (there can
be more than one preferred type in a category, and in fact the
traditional setup is that *every* user-defined type is a preferred
type in the USER_TYPE category).
Perhaps tangential: What does it mean for a type to be "preferred"?
The categories themselves are pretty much opaque values, except that
parse_func.c has special behavior to prefer STRING_TYPE when in doubt.
So this can fairly obviously be replaced by two new pg_type columns,
say "typcategory" and "typpreferred", where the latter is a bool.
Since the list of categories is pretty short and there's no obvious
reason to extend it a lot, I propose that we just represent
typcategory
as a "char", using a mapping along the lines of
BITSTRING_TYPE b
BOOLEAN_TYPE B
DATETIME_TYPE D
GENERIC_TYPE P (think "pseudotype")
GEOMETRIC_TYPE G
INVALID_TYPE \0 (not allowed in catalog anyway)
NETWORK_TYPE n
NUMERIC_TYPE N
STRING_TYPE S
TIMESPAN_TYPE T
UNKNOWN_TYPE u
USER_TYPE U
Users would be allowed to select any single ASCII character as the
"category" of a user-defined type, should they have a need to make
their
own new category.
Wouldn't this then limit them to 52 possible categories? Does that
matter? Given your suggestion, I'm assuming that a single character is
somehow more efficient than an enum, yes?
Of course CREATE TYPE's default is category = U and
preferred = true for backward compatibility reasons. We could put
down
a rule that system-defined categories are always upper or lower case
letters (or even always upper, if we wanted to strain some of the
assignments a bit) so that it's clear what can be used for a
user-defined category.
Makes sense.
It might possibly be worth making new categories for arrays,
composites,
and enums; they're currently effectively USER_TYPE but that doesn't
seem
quite right. Also, the rules for domains should likely be "same
category as base type, never a preferred type" instead of the current
behavior where they're user types. (I think the latter doesn't really
matter now, because we always smash a domain to its base type before
inquiring about categories anyway. But it might give Elein a bit more
room to maneuver with the functions-on-domains issue.)
Yes, this all sounds like it'd be an important improvement.
A possible objection is that this will make TypeCategory and
IsPreferredType slower than before, since they'll involve a syscache
lookup instead of a simple switch statement. I don't think this will
be too bad though; all the paths they are used in are full of catalog
lookups anyway, so it's hard to credit that there would be much
percentage slowdown.
Thoughts?
Obviously I don't know much about the internals, but your explanation
here seems very clear to me. I like it. +1
Thank you, Tom.
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
