Re: BUG #8228: Unexpected "set-valued function" with varchar(n) but not varchar

David Johnston <david(dot)g(dot)johnston(at)gmail(dot)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