From: | Vik Fearing <vik(at)postgresfriends(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Standard REGEX functions |
Date: | 2022-12-18 23:15:46 |
Message-ID: | 538f4e3a-7009-b301-8bd6-12d33ee40592@postgresfriends.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/18/22 15:24, Tom Lane wrote:
> Vik Fearing <vik(at)postgresfriends(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2022-12-18 23:30:18 | Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX |
Previous Message | Peter Geoghegan | 2022-12-18 22:20:49 | Re: New strategies for freezing, advancing relfrozenxid early |