Re: Do we really want to migrate plproxy and citext into PG core distribution? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Do we really want to migrate plproxy and citext into PG core distribution?
Date
Msg-id 13881.1217356900@sss.pgh.pa.us
Whole thread Raw
In response to Re: Do we really want to migrate plproxy and citext into PG core distribution?  ("David E. Wheeler" <david@kineticode.com>)
Responses Re: Do we really want to migrate plproxy and citext into PG core distribution?  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
List pgsql-hackers
"David E. Wheeler" <david@kineticode.com> writes:
> Sure. It's mostly just additional casts and tests. I'd be happy to  
> integrate it into your commit.

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

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, 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.

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.

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.

Anyway, debating that is probably material for a separate thread ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Robert Haas"
Date:
Subject: Re: [PATCH] "\ef " in psql
Next
From: David E. Wheeler
Date:
Subject: Type Categories for User-Defined Types