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.
> 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.
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.
regards, tom lane
