Thread: Standard REGEX functions
The standard uses XQuery regular expressions, which I believe are subtly different from ours. Because of that, I had been hesitant to add some standard functions to our library such as <regex occurrences function>. While looking at commit 6424337073589476303b10f6d7cc74f501b8d9d7 from last year (which will come up soon from somebody else for a different reason), I noticed that we added those functions for Oracle compatibility even though the regexp language was not the same. Are there any objections to me writing a patch to add SQL Standard regular expression functions even though they call for XQuery and we would use our own language? -- Vik Fearing
Vik Fearing <vik@postgresfriends.org> writes:
> Are there any objections to me writing a patch to add SQL Standard
> regular expression functions even though they call for XQuery and we
> would use our own language?
Yes. If we provide spec-defined syntax it should have spec-defined
behavior. I really don't see the value of providing different
syntactic sugar for functionality we already have, unless the point
of it is to be spec-compliant, and what you suggest is exactly not
that.
I recall having looked at the points of inconsistency (see 9.7.3.8)
and thought that we could probably create an option flag for our regex
engine that would address them, or at least get pretty close. It'd
take some work though, especially for somebody who never looked at
that code before.
I'd be willing to blow off the locale discrepancies by continuing
to say that you have to use an appropriate locale, and I think the
business around varying newline representations is in the way-more-
trouble-than-its-worth department. But we should at least match
the spec on available escape sequences and flag names. It would
be a seriously bad idea, for example, if the default
does-dot-match-newline behavior wasn't per spec.
regards, tom lane
On 12/18/22 15:24, Tom Lane wrote: > Vik Fearing <vik@postgresfriends.org> writes: >> Are there any objections to me writing a patch to add SQL Standard >> regular expression functions even though they call for XQuery and we >> would use our own language? > > Yes. If we provide spec-defined syntax it should have spec-defined > behavior. I really don't see the value of providing different > syntactic sugar for functionality we already have, unless the point > of it is to be spec-compliant, and what you suggest is exactly not > that. I was expecting this answer and I can't say I disagree with it. > I recall having looked at the points of inconsistency (see 9.7.3.8) Oh sweet! I was not aware of that section. > and thought that we could probably create an option flag for our regex > engine that would address them, or at least get pretty close. It'd > take some work though, especially for somebody who never looked at > that code before. Yeah. If I had the chops to do this, I would have tackled row pattern recognition long ago. I don't suppose project policy would allow us to use an external library. I assume there is one out there that implements XQuery regular expressions. -- Vik Fearing
Vik Fearing <vik@postgresfriends.org> writes:
> I don't suppose project policy would allow us to use an external
> library. I assume there is one out there that implements XQuery regular
> expressions.
Probably, but is it in C and does it have a compatible license?
The bigger picture here is that our track record with use of external
libraries is just terrible: we've outlived the original maintainers'
interest multiple times. (That's how we got to the current situation
with the regex code, for example.) So I'd want to see a pretty darn
vibrant-looking upstream community for any new dependency we adopt.
regards, tom lane