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

On Fri, Aug 9, 2013 at 12:23:59PM -0400, Bruce Momjian wrote:
> 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.

[ moved to hackers ]

Based on my research, I am now proposing a new, attached patch which
eliminates comma in all places in TRIM, e.g. this is no longer valid
either:

SELECT trim(BOTH FROM 'abc', 'a');
btrim
-------
bc
(1 row)

I believe the flexible TRIM syntax was introduced when TRIM was added in
1997:

commit 570620c5698b0c76b26a3ec71692df29375cad16
Author: Thomas G. Lockhart <lockhart(at)fourpalms(dot)org>
Date: Mon Sep 1 06:00:35 1997 +0000

Add SQL92 string handling features (SUBSTRING, TRIM, EXTRACT).

We would now only support the documented TRIM syntax.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +