On 15.12.21 14:15, Gilles Darold wrote:
Le 15/12/2021 à 13:41, Peter Eisentraut a écrit :
On 03.08.21 19:10, Tom Lane wrote:
Gilles Darold writes:
Sorry I have missed that, but I'm fine with this implemenation so let's
keep the v6 version of the patch and drop this one.
Pushed, then.
Le 15/12/2021 à 13:41, Peter Eisentraut a écrit :
On 03.08.21 19:10, Tom Lane wrote:
Gilles Darold writes:
Sorry I have missed that, but I'm fine with this implemenation so let's
keep the v6 version of the patch and drop this one.
Pushed, then. There's still lots of time to tweak the
On 03.08.21 19:10, Tom Lane wrote:
Gilles Darold writes:
Sorry I have missed that, but I'm fine with this implemenation so let's
keep the v6 version of the patch and drop this one.
Pushed, then. There's still lots of time to tweak the behavior of course.
I have a documentation follow-up
Gilles Darold writes:
> Sorry I have missed that, but I'm fine with this implemenation so let's
> keep the v6 version of the patch and drop this one.
Pushed, then. There's still lots of time to tweak the behavior of course.
regards, tom lane
Le 03/08/2021 à 15:39, Tom Lane a écrit :
Erik Rijkers writes:
On 8/3/21 1:26 PM, Gilles Darold wrote:
Le 03/08/2021 à 11:45, Gilles Darold a écrit :
Actually I just found that the regexp_like() function doesn't support
the start parameter which is something we should support. I saw that
Erik Rijkers writes:
> On 8/3/21 1:26 PM, Gilles Darold wrote:
>> Le 03/08/2021 à 11:45, Gilles Darold a écrit :
>>> Actually I just found that the regexp_like() function doesn't support
>>> the start parameter which is something we should support. I saw that
>>> Oracle do not support it but
On 8/3/21 1:26 PM, Gilles Darold wrote:
Le 03/08/2021 à 11:45, Gilles Darold a écrit :
Actually I just found that the regexp_like() function doesn't support
the start parameter which is something we should support. I saw that
Oracle do not support it but DB2 does and I think we should also
Le 03/08/2021 à 11:45, Gilles Darold a écrit :
Actually I just found that the regexp_like() function doesn't support
the start parameter which is something we should support. I saw that
Oracle do not support it but DB2 does and I think we should also
support it. I will post a new version of
Le 02/08/2021 à 23:22, Gilles Darold a écrit :
Le 02/08/2021 à 01:21, Tom Lane a écrit :
Gilles Darold writes:
[ v5-0001-regexp-foo-functions.patch ]
I've gone through this whole patch now, and found quite a lot that I did
not like. In no particular order:
* Wrapping parentheses around the
Le 02/08/2021 à 01:21, Tom Lane a écrit :
> Gilles Darold writes:
>> [ v5-0001-regexp-foo-functions.patch ]
> I've gone through this whole patch now, and found quite a lot that I did
> not like. In no particular order:
>
> * Wrapping parentheses around the user's regexp doesn't work. It can
>
I wrote:
> ... aside from the question of whether
> a too-large subexpression number should be an error or not.
Oh ... poking around some more, I noticed a very nearby precedent.
regexp_replace's replacement string can include \1 to \9 to insert
the substring matching the N'th parenthesized
Gilles Darold writes:
> [ v5-0001-regexp-foo-functions.patch ]
I've gone through this whole patch now, and found quite a lot that I did
not like. In no particular order:
* Wrapping parentheses around the user's regexp doesn't work. It can
turn an invalid regexp into a valid one: for example
Le 01/08/2021 à 19:23, Tom Lane a écrit :
> I've been working through this patch, and trying to verify
> compatibility against Oracle and DB2, and I see some points that need
> discussion or at least recording for the archives.
>
> * In Oracle, while the documentation for regexp_instr says that
>
Le 30/07/2021 à 23:38, Tom Lane a écrit :
> Gilles Darold writes:
>> Le 26/07/2021 à 21:56, Tom Lane a écrit :
>>> I'm inclined to just drop the regexp_replace additions. I don't think
>>> that the extra parameters Oracle provides here are especially useful.
>>> They're definitely not useful
I've been working through this patch, and trying to verify
compatibility against Oracle and DB2, and I see some points that need
discussion or at least recording for the archives.
* In Oracle, while the documentation for regexp_instr says that
return_option should only be 0 or 1, experimentation
Gilles Darold writes:
> Le 26/07/2021 à 21:56, Tom Lane a écrit :
>> I'm inclined to just drop the regexp_replace additions. I don't think
>> that the extra parameters Oracle provides here are especially useful.
>> They're definitely not useful enough to justify creating compatibility
>> hazards
Le 26/07/2021 à 21:56, Tom Lane a écrit :
> Gilles Darold writes:
>> [ v4-0001-regexp-foo-functions.patch ]
> I started to work through this and was distressed to realize that
> it's trying to redefine regexp_replace() in an incompatible way.
> We already have
>
> regression=# \df regexp_replace
Gilles Darold writes:
> [ v4-0001-regexp-foo-functions.patch ]
I started to work through this and was distressed to realize that
it's trying to redefine regexp_replace() in an incompatible way.
We already have
regression=# \df regexp_replace
List of functions
Le 21/03/2021 à 15:53, Tom Lane a écrit :
> Chapman Flack writes:
>> If this turns out to be a case of "attached the wrong patch, here's
>> the one that does implement foo_regex functions!" then I reserve an
>> objection to that. :)
>>
And the patch renamed.
diff --git a/doc/src/sgml/func.sgml
Le 21/03/2021 à 15:53, Tom Lane a écrit :
> Chapman Flack writes:
>> If this turns out to be a case of "attached the wrong patch, here's
>> the one that does implement foo_regex functions!" then I reserve an
>> objection to that. :)
> +1 to that. Just to add a note, I do have some ideas about
Chapman Flack writes:
> If this turns out to be a case of "attached the wrong patch, here's
> the one that does implement foo_regex functions!" then I reserve an
> objection to that. :)
+1 to that. Just to add a note, I do have some ideas about extending
our regex parser so that it could
On 03/21/21 09:19, Gilles Darold wrote:
>>> On 2021.03.20. 19:48 Gilles Darold wrote:
>>>
>>> This is a new version of the patch that now implements all the XQUERY
>>> regexp functions as described in the standard, minus the differences of
>>> PostgerSQL regular expression explain in [1].
>>>
Le 21/03/2021 à 12:07, e...@xs4all.nl a écrit :
>> On 2021.03.20. 19:48 Gilles Darold wrote:
>>
>> This is a new version of the patch that now implements all the XQUERY
>> regexp functions as described in the standard, minus the differences of
>> PostgerSQL regular expression explain in [1].
>>
> On 2021.03.20. 19:48 Gilles Darold wrote:
>
> This is a new version of the patch that now implements all the XQUERY
> regexp functions as described in the standard, minus the differences of
> PostgerSQL regular expression explain in [1].
>
> The standard SQL describe functions like_regex(),
Le 20/03/2021 à 19:48, Gilles Darold a écrit :
>
> Hi,
>
>
> This is a new version of the patch that now implements all the XQUERY
> regexp functions as described in the standard, minus the differences
> of PostgerSQL regular expression explain in [1].
>
>
> The standard SQL describe functions
Hi,
This is a new version of the patch that now implements all the XQUERY
regexp functions as described in the standard, minus the differences of
PostgerSQL regular expression explain in [1].
The standard SQL describe functions like_regex(), occurrences_regex(),
position_regex(),
My apologies for the links in the head, the email formatting and the
missing patch, I accidently send the email too early.
--
Gilles
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index bf99f82149..88e08b40d2 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@
Oracle:
https://docs.oracle.com/en/database/oracle/oracle-database/18/adfns/regexp.html#GUID-F14733F3-B943-4BAD-8489-F9704986386B
IBM:
https://www.ibm.com/support/producthub/db2/docs/content/SSEPGG_11.5.0/com.ibm.db2.luw.sql.ref.doc/doc/r0061494.html?pos=2
Z/OS:
28 matches
Mail list logo
