On Mon, Aug 12, 2013 at 04:58:23PM -0400, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
Bruce Momjian <bruce@momjian.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.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?
The second line is wrong no? We don't allow the LEADING etc keywordstrim([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?
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.
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.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.
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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
