Type Categories for User-Defined Types

On Jul 29, 2008, at 11:41, Tom Lane wrote:

> Okay, it's committed with minor revisions --- the biggest thing I
> fixed
> was the lack of an uninstall script.

Great, thanks!

> I saw what you were talking about in terms of still having some
> casting
> issues: having to put in a quote_literal(citext) alias function seems
> like a huge hack,

Yes, and I've been adding more hacks along the lines of:

CREATE OR REPLACE FUNCTION int8(citext)
RETURNS int8
AS 'SELECT int8( $1::text )'
LANGUAGE SQL IMMUTABLE STRICT;

CREATE OR REPLACE FUNCTION citext(int8)
RETURNS citext
AS 'SELECT text( $1 )::citext'
LANGUAGE SQL IMMUTABLE STRICT;

CREATE CAST (int8 AS citext) WITH FUNCTION citext(int8) AS ASSIGNMENT;
CREATE CAST (citext AS int8) WITH FUNCTION int8(citext);

I've been doing this for all the types, writing tests to see how text
behaves and replicating it with these hack functions. No, it's not
ideal.

> and I notice that cases like
>
> contrib_regression=# select 'a'::text || 'b'::citext;
> ERROR: operator is not unique: text || citext
>
> still don't work even though you put in an alias || operator.

Damn, I didn't even notice that! Can that be fixed?

> It seems to me that trying to fix these things retail is a losing
> proposition. The reason you need these, instead of having everything
> "just work" like varchar does, is that citext isn't seen as a member
> of the string type category, and so the "preferred type" preference
> for
> text isn't applied. What we ought to do about that IMHO is make a
> way for user-defined types to declare what category they belong to.
> This has been foreseen as needed for a *very* long time, but we never
> really had a forcing function to make us do it before.

Yes, this would be a *much* nicer way to do it, IMO.

> Obviously the solution should involve a new column in pg_type and
> a new type property in CREATE TYPE, but what should the representation
> be? A full-on approach would make the type categories be real SQL
> objects with their own system catalog and reference them by OID,
> but I can't help thinking that that's overkill.

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?

> Anyway, debating that is probably material for a separate thread ...

Here you go! ;-)

Thanks again for the commit, Tom.

Best,

David