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

Finally could make it using
regexp_replace (my_field_to_trim, '.+my_triming_string' , '') for the "lead=
ing" case

regexp_replace (my_field_to_trim, 'my_triming_string(.+)' , '') for the "tr=
ailing" case

And both of them in this order a for the "both" one.
I don't know why, but=C2=A0 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=C2=A0: Bruce Momjian [via PostgreSQL] <ml-node+s1045698n5766983h79@n5.n=
abble.com>
=C3=80=C2=A0: Romain Billon-Grand <romainbillongrand@yahoo.fr>=20
Envoy=C3=A9 le : Vendredi 9 ao=C3=BBt 2013 18h24
Objet=C2=A0: Re: BUG #8335: trim() un-document behaviour
=20


On Fri, Aug =C2=A09, 2013 at 11:06:15AM -0400, Tom Lane wrote:=20

> Bruce Momjian <[hidden email]> writes:=20
> > The attached patch swaps the arguments in the parser, and allows your=
=20
> > expected behavior:=20
>=20
> This patch is completely unsafe. =C2=A0It will break stored rules, which =
may=20
> contain calls using the existing argument order (which will be dumped=20
> without any of the SQL-spec syntactic sugar). =C2=A0To say nothing of exi=
sting=20
> applications that may be relying on calling the underlying functions with=
=20
> their existing argument order.=20
>=20
> The inconsistency in argument order is unfortunate but we're long since=
=20
> stuck with it, I'm afraid.=20
Yes, I have thought about this some more and another problem is that=20
rtrim/btrim/ltrim() use the source string first, so having trim() have=20
the source string second when using a comma is very confusing, e.g.:=20

=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- with patch=20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SELECT trim('x', 'xabcx');=20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0btrim=20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -------=20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0abc=20

=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- btrim=20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SELECT btrim('xabcx', 'x');=20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0btrim=20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -------=20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0abc=20

I think we can either document what we have, or remove the ability to=20
use comma with trim(). =C2=A0If we go with documentation, it is going to lo=
ok=20
confusing as the optional modifier is going to be on the source string,=20
e.g.:=20

=C2=A0 =C2=A0 =C2=A0 =C2=A0 SELECT trim(both 'xabcx', 'x');=20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0btrim=20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -------=20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0abc=20

We could modify the grammar to force the modifier on the second=20
argument, but that is more parser states for limited value.=20

--=20
=C2=A0 Bruce Momjian =C2=A0<[hidden email]> =C2=A0 =C2=A0 =C2=A0 =C2=A0http=
://momjian.us
=C2=A0 EnterpriseDB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://enterprisedb.com

=C2=A0 + It's impossible for everything to be true. +=20


--=20
Sent via pgsql-bugs mailing list ([hidden email])=20
To make changes to your subscription:=20
http://www.postgresql.org/mailpref/pgsql-bugs


________________________________
=20
If you reply to this email, your message will be added to the discussion be=
low:http://postgresql.1045698.n5.nabble.com/BUG-8335-trim-un-document-behav=
iour-tp5765221p5766983.html=20
To unsubscribe from BUG #8335: trim() un-document behaviour, click here.
NAML



--
View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-8=
335-trim-un-document-behaviour-tp5765221p5767148.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.