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

On Mon, Aug 12, 2013 at 04:58:23PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > We did have someone confused by what we have now, as well as me, so I
> > think there is a reason to clean this up. It would be a
> > backward-compatible change, though.
>
> backward-INcompatible, I assume you meant.

Yes.

> > To document this, I think we would need to add only one line:
>
> > trim([leading | trailing | both] [characters] from string)
> > new trim([leading | trailing | both] [from] string [, characters])
>
> > Of course, that second line is non-standard --- do we have to mention
> > that?
>
> The second line is wrong no? We don't allow the LEADING etc keywords
> in the expr_list alternative. Anyway, I'm dubious that we really want
> to document a nonstandard syntax --- that would just be encouraging
> people to use it, to little benefit.

Well, we just call trim_list rule the TRIM keyword rule, so it sure does
work:

SELECT trim(LEADING FROM 'abc', 'a');
ltrim
-------
bc

So, you are saying we should just leave it undocumented? It is true we
have gotten near-zero complaints about it in the past.

> Now that I've thought about this some more, I think that there was some
> previous discussion around this syntax production, and that the reason
> we left it like this is that we wanted to leave the door open for
> user-defined trim functions that might take extra arguments. That
> discussion probably predated 7.3 (when we added schemas) because the
> code's current habit of forcing a "pg_catalog" prefix would make it
> a little bit painful to add such functions. Still, you could do it
> with superuser privileges. Not sure how strong that argument is,
> but I think that's where we left it years ago.

Oh, that does make sense why we had this syntax so open.

Attached are docs that add the new syntax, and mention it is
non-standard; you can see the output here:

http://momjian.us/tmp/pgsql/functions-string.html#FUNCTIONS-STRING-SQL

We do document three syntaxes for substring() in the same table, one row
for each, so there is precedent for doing this.

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

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