I wrote:
> This will break even more stuff than the last patch, ie, every single
> stored rule or view that contains a TRIM function. You can *not*
> eliminate, or mess with, the expr_list production, because that's what
> dumping of these function calls relies on.
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.
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
