Re: [BUGS] BUG #8335: trim() un-document behaviour
Running postgres 9.1.4 using pgAdmin3 on a macbook air intel OS 10.6 I just had this bug, using comma: SELECT trim(trailing texte_natif , 'DATEDENAISSANCE' ) FROM CROP returned the whole field, including the string 'DATEDENAISSANCE', but except the very first character, the column being called rtrim. Tryed to chang it to SELECT trim(trailing texte_natif from 'DATEDENAISSANCE' ) FROM CROP returned nothing ( as a dummy in postgres I can't say if it was null fields or empty string...) CROP.texte_natif is a quite long texte field,in which the STRING 'DATEDENAISSANCE can be present 0 to 3 times, and never before 20th character bests Romain -- View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-8335-trim-un-document-behaviour-tp5765221p5766930.html Sent from the PostgreSQL - bugs mailing list archive at Nabble.com. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8335: trim() un-document behaviour
Bruce Momjian br...@momjian.us 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. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8335: trim() un-document behaviour
On Fri, Aug 9, 2013 at 11:06:15AM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us 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 br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
