David Johnston <david.g.johns...@gmail.com> writes:
> The issue with the regexp_matches call generally is that absence of a "g"
> modifier means that the set-returning function will never return a set. It
> would seem to make more sense to not make that a modifier but instead have
> one function defined to return a set (i.e., the current definition) and
> another one defined to return a simply text[].
Well, it does return a set, namely either zero or one row. The point of
the sub-SELECT workaround is to transform the zero-row case to a scalar
NULL.
I tend to agree that this API wasn't that well thought out, but it's
really not regexp_matches()'s fault that you're running into this
problem --- rather, it's the fact that one arm of the CASE can return a
set while the other can't.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
