Re: Do we really want to migrate plproxy and citext into PG core distribution?

"David E. Wheeler" <david(at)kineticode(dot)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