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@fourpalms.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@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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