Peter Eisentraut <peter@eisentraut.org> writes:
> This patch allows using regular expression functions and operators with
> nondeterministic collations.
> ...
> In summary, this patch doesn't change any functionality that currently
> works. It just removes one error message and lets regular expressions
> just run, independent of whether the collation is nondeterministic.
I kind of wonder if we really want to do this. It adds no
functionality, and it forecloses the possibility of changing
the definition later. I understand and agree with your conclusion
that it's pretty much impossible to do what the SQL standard suggests
should happen --- but maybe we're both missing something that would
make it feasible. (Have you asked your committee colleagues if
anyone's actually implemented what they wrote about SIMILAR TO?
If they've written something unimplementable, it seems like there
is work for them to do in any case.)
On the whole I'm content with our status quo here.
If we do push forward with this, I doubt that it's okay to throw
the error for SIMILAR TO from where you have it --- it will leak
the partially-built compiled regex, and that will be a
session-lifespan leak. The way forward is illustrated by code
just above: it'd have to look more like
if (!collation-is-allowed)
return freev(v, REG_ECOLLATION);
where you'd need to invent a new regex error code REG_ECOLLATION
and plug that into the appropriate places.
regards, tom lane
