Re: Type Categories for User-Defined Types

"David E. Wheeler" <david(at)kineticode(dot)com> writes:
> On Jul 29, 2008, at 13:12, Tom Lane wrote:
>> 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.

Well, a rough estimate of the places where implicit coercion to text
might be relevant to resolving ambiguity is

select proname from pg_proc
where 'text'::regtype = any(proargtypes)
group by proname having count(*)>1;

select oprname from pg_operator
where oprleft='text'::regtype or oprright='text'::regtype
group by oprname having count(*)> 1;

I count 37 functions and 10 operators as of CVS HEAD. Perhaps not all
would need to be fixed in practical use, but if you wanted seamless
integration of citext it's quite possible that you'd need alias
functions/operators (maybe more than one) in each of those cases.

[ squint... ] Actually, this is an underestimate since these queries
aren't finding cases like quote_literal, where there is ambiguity but
only one of the alternatives takes 'text'. I'm too lazy to work out a
better query though.

> Perhaps tangential: What does it mean for a type to be "preferred"?

See the ambiguous-function resolution rules in chapter 10 of the fine
manual ...

>> 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?

It'd be either 94 - 26 or 94 - 26 - 26 depending on what the policy is
about lower-case letters (and assuming they wanted to stay away from
control characters, which seems like a good idea). Considering the
world supply of categories up to now has been about ten, it's hard
to imagine that this is really a limitation.

> Does that
> matter? Given your suggestion, I'm assuming that a single character is
> somehow more efficient than an enum, yes?

Marginally so; but an enum wouldn't help anyway unless we are prepared
to invent ALTER ENUM. We'd have to go to an actual new system catalog
if we wanted something noticeably better than the poor-mans-enum
approach, and as I mentioned earlier, that just seems like overkill.
(Besides, we could always add it later if there's suddenly a gold rush
for categories. The only thing we'd be locking ourselves into, if
we view this as a stopgap implementation, is the need to accept
single-character abbreviations in future, even after the system knows
actual names for categories.)

regards, tom lane