Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace - Mailing list pgsql-hackers

From Gilles Darold
Subject Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace
Date
Msg-id 2204c4a4-8ee8-abdd-d5ca-d0b6893f96ab@darold.net
Whole thread Raw
In response to Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Le 26/07/2021 à 21:56, Tom Lane a écrit :
> Gilles Darold <gillesdarold@gmail.com> 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
>    Schema   |      Name      | Result data type |  Argument data types   | Type
> ------------+----------------+------------------+------------------------+------
>  pg_catalog | regexp_replace | text             | text, text, text       | func
>  pg_catalog | regexp_replace | text             | text, text, text, text | func
> (2 rows)
>
> The patch proposes to add (among other alternatives)
>
> +{ oid => '9608', descr => 'replace text using regexp',
> +  proname => 'regexp_replace', prorettype => 'text',
> +  proargtypes => 'text text text int4', prosrc => 'textregexreplace_extended_no_occurrence' },
>
> which is going to be impossibly confusing for both humans and machines.
> I don't think we should go there.  Even if you managed to construct
> examples that didn't result in "ambiguous function" failures, that
> doesn't mean that ordinary mortals won't get bit that way.
>
> 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 for.


I would not say that being able to replace the Nth occurrence of a
pattern matching is not useful but i agree that this is not a common
case with replacement. Both Oracle [1] and IBM DB2 [2] propose this form
and I have though that we can not have compatibility issues because of
the different data type at the 4th parameter. Anyway, maybe we can just
rename the function even if I would prefer that regexp_replace() be
extended. For example:


    regexp_replace(source, pattern, replacement [, flags ]);

    regexp_substitute(source, pattern, replacement [, position ] [,
occurrence ] [, flags ]);


of course with only 3 parameters the two functions are the same.


What do you think about the renaming proposal instead of simply drop the
extended form of the function?


Best regards,


[1] https://docs.oracle.com/database/121/SQLRF/functions163.htm#SQLRF06302

[2] https://www.ibm.com/docs/en/db2oc?topic=functions-regexp-replace


--
Gilles Darold
http://www.darold.net/





pgsql-hackers by date:

Previous
From: Matthias van de Meent
Date:
Subject: Re: ATTACH PARTITION locking documentation for DEFAULT partitions
Next
From: Daniel Gustafsson
Date:
Subject: Re: pg_settings.pending_restart not set when line removed