Expanding regexp_matches flags
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.
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