Re: BUG #8335: trim() un-document behaviour

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+s1045698n5766983h79(at)n5(dot)nabble(dot)com>
À : Romain Billon-Grand <romainbillongrand(at)yahoo(dot)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.