On Mon, Aug 12, 2013 at 02:18:01PM -0400, Tom Lane wrote:
> No, wait, I take that back. I was thinking that the function call would
> dump out as trim(x, y) but actually none of the underlying functions
> are named just "trim"; they're btrim, ltrim, or rtrim. So actually the
> dump/reload scenario does not have anything to do with the trim_list
> production --- the underlying functions just parse normally in any case.
Right, TRIM is really just a wrapper around btrim/rtrim/ltrim.
> The question remains why it's a good idea to mess with a syntax behavior
> that's been like that for a dozen years or more. I don't see any upside
> to doing that. As an example of a downside, right now if you try to
> pass extra arguments to TRIM() you'll get
>
> regression=# select trim(1,2,3);
> ERROR: function pg_catalog.btrim(integer, integer, integer) does not exist
> LINE 1: select trim(1,2,3);
> ^
> HINT: No function matches the given name and argument types. You might need to add explicit type casts.
>
> You might wonder why the message mentions "btrim" not "trim", but at least
> the complaint is reasonably on-topic. After this patch, you'd just get
> a "syntax error" message, which doesn't seem helpful at all.
Well, btrim/rtrim/ltrim only take two arguments, so allowing three for
it to fail later really doesn't seem to help much, compared to a syntax
error.
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.
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?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
