From: | Gilles Darold <gilles(at)darold(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gilles Darold <gillesdarold(at)gmail(dot)com> |
Cc: | Chapman Flack <chap(at)anastigmatix(dot)net>, er(at)xs4all(dot)nl, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace |
Date: | 2021-07-27 09:38:36 |
Message-ID: | 2204c4a4-8ee8-abdd-d5ca-d0b6893f96ab@darold.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Le 26/07/2021 à 21:56, Tom Lane a écrit :
> Gilles Darold <gillesdarold(at)gmail(dot)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/
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2021-07-27 09:45:03 | Re: pg_settings.pending_restart not set when line removed |
Previous Message | Matthias van de Meent | 2021-07-27 09:35:53 | Re: ATTACH PARTITION locking documentation for DEFAULT partitions |