Thread: Expanding regexp_matches flags

Expanding regexp_matches flags

From
Jordan Gigov
Date:
A recent thread gave me the idea that it would be convenient to have
another flag for `regexp_matches` to make it return a singular
two-dimensional array of matches when performing a global match.

Why? Well, basically you avoid having to aggregate the rows afterwards
using by wrapping it in a subquery.

Is there some interest in this?

The idea is to add a new flag `a` that would imply `g` internally when
performing the match, but then return an array, instead of a set. Or
more accurately it will return a set that will always have exactly one
array. The array would be empty if no matches are found, or would
contain arrays of match results otherwise.

I have not looked into implementing this yet, but I may have time in
8-9 days or so.

For now, I'm just looking if there's support or opposition to the idea.



Re: Expanding regexp_matches flags

From
Tom Lane
Date:
Jordan Gigov <coladict@gmail.com> writes:
> A recent thread gave me the idea that it would be convenient to have
> another flag for `regexp_matches` to make it return a singular
> two-dimensional array of matches when performing a global match.

> Why? Well, basically you avoid having to aggregate the rows afterwards
> using by wrapping it in a subquery.

> Is there some interest in this?

I'm not really convinced that has any value.  The first question you
ought to be answering is whether the recently-pushed regexp function
additions don't already serve whatever use-case you had in mind.

If we do do it, I think it ought to be a different function.  "flag"
values that utterly change the meaning of the output sound like a
pretty bad idea.  Also, "returns setof text[]" is very different from
"returns text[]".  The primary reason we invented regexp_match() a few
years ago was to get away from the ugliness involved in trying to
pretend the former is the latter.

            regards, tom lane