Finally could make it using
regexp_replace (my_field_to_trim, '.+my_triming_string' , '') for the "leading"
case
regexp_replace (my_field_to_trim, 'my_triming_string(.+)' , '') for the
"trailing" case
And both of them in this order a for the "both" one.
I don't know why, but could not use '*?'
Since in no instance my_triming_string was at the extremlity of the sting, I
did not need it, but I guess something like '(|.+)my_triming_string'could have
worked
________________________________
De : Bruce Momjian [via PostgreSQL] <ml-node+s1045698n5766983...@n5.nabble.com>
À : Romain Billon-Grand <romainbillongr...@yahoo.fr>
Envoyé le : Vendredi 9 août 2013 18h24
Objet : Re: BUG #8335: trim() un-document behaviour
On Fri, Aug 9, 2013 at 11:06:15AM -0400, Tom Lane wrote:
> Bruce Momjian <[hidden email]> writes:
> > The attached patch swaps the arguments in the parser, and allows your
> > expected behavior:
>
> This patch is completely unsafe. It will break stored rules, which may
> contain calls using the existing argument order (which will be dumped
> without any of the SQL-spec syntactic sugar). To say nothing of existing
> applications that may be relying on calling the underlying functions with
> their existing argument order.
>
> The inconsistency in argument order is unfortunate but we're long since
> stuck with it, I'm afraid.
Yes, I have thought about this some more and another problem is that
rtrim/btrim/ltrim() use the source string first, so having trim() have
the source string second when using a comma is very confusing, e.g.:
-- with patch
SELECT trim('x', 'xabcx');
btrim
-------
abc
-- btrim
SELECT btrim('xabcx', 'x');
btrim
-------
abc
I think we can either document what we have, or remove the ability to
use comma with trim(). If we go with documentation, it is going to look
confusing as the optional modifier is going to be on the source string,
e.g.:
SELECT trim(both 'xabcx', 'x');
btrim
-------
abc
We could modify the grammar to force the modifier on the second
argument, but that is more parser states for limited value.
--
Bruce Momjian <[hidden email]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
________________________________
If you reply to this email, your message will be added to the discussion
below:http://postgresql.1045698.n5.nabble.com/BUG-8335-trim-un-document-behaviour-tp5765221p5766983.html
To unsubscribe from BUG #8335: trim() un-document behaviour, click here.
NAML
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/BUG-8335-trim-un-document-behaviour-tp5765221p5767148.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.
