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

On Fri, Aug 9, 2013 at 11:06:15AM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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