In
http://www.postgresql.org/message-id/BN1PR04MB37467AA1D412223B3D4A595DFD20@BN1PR04MB374.namprd04.prod.outlook.com
it's revealed that the citext extension misdeclares its versions of
regexp_matches(): they should return SETOF text[] but they're marked
as returning just text[].
We know generally how to fix this sort of thing: create a new version of
the citext extension and provide an upgrade script that repairs the error.
However there are a couple of points that deserve discussion.
* We can't use CREATE OR REPLACE FUNCTION in the upgrade script because
that intentionally doesn't let you change the result type of an existing
function. I considered doing a manual UPDATE of the pg_proc entry, but
then remembered why CREATE OR REPLACE FUNCTION is picky about this: the
result type, including set-ness, is embedded in the parse tree of any view
referencing the function. So AFAICS we need to actually drop and recreate
the citext regexp_matches() functions in the upgrade script. That means
"ALTER EXTENSION citext UPDATE" will fail if these functions are being
used in any views. That's annoying but I see no way around it. (We
could have the upgrade script do DROP CASCADE, but that seems way too
destructive.)
* Is anyone concerned about back-patching this fix? I suppose you could
make an argument that some app somewhere might be relying on the current
behavior of citext regexp_matches(), which effectively is to return only
the first match even if you said 'g'. One answer would be to keep on
supplying the citext 1.0 script in the back branches, so that anyone who
really needed it could still install 1.0 not 1.1. That's not our usual
practice though, so unless there's serious concern that such a problem
really exists, I'd rather not do that.
Comments?
regards, tom lane
