Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Here is a patch to reimplement the xmlconcat functionality as a variadic
function instead of a hardcoded special expression type.
What's the point of this? I suppose making xmlconcat not a keyword is
some small advantage, but having it behave subtly differently from the
other xmlfoo functions isn't really all that nice.
Different from what and how? We already have a mix of XML functions
implemented in user space and some as built-in expressions. And they
all have different signatures and purposes, so I don't see a lot of need
to align anything here.
If variadic functions had been available in 8.3, we would probably have
implemented xmlconcat like this in the first place.
And the change in
this error message is not for the better:
*** 55,63 ****
(1 row)
SELECT xmlconcat(1, 2);
! ERROR: argument of XMLCONCAT must be type xml, not type integer
LINE 1: SELECT xmlconcat(1, 2);
! ^
SELECT xmlconcat('bad', '<syntax');
ERROR: invalid XML content
LINE 1: SELECT xmlconcat('bad', '<syntax');
--- 55,64 ----
(1 row)
SELECT xmlconcat(1, 2);
! ERROR: function xmlconcat(integer, integer) does not exist
LINE 1: SELECT xmlconcat(1, 2);
! ^
! HINT: No function matches the given name and argument types. You might need
to add explicit type casts.
SELECT xmlconcat('bad', '<syntax');
ERROR: invalid XML content
LINE 1: SELECT xmlconcat('bad', '<syntax');
If you think this is a problem, then it can be fixed. I never
particularly liked this second error message in general. A much better
hint that would address this case and many others might be:
ERROR: function foo(type, type) does not exist
HINT: There is foo(type, type) and foo(type, type) instead.
There are a number of other distinguishable cases that call for better
hints, e.g., no foo() exists at all. I think in my experience, "you
need to add explicit type casts" has almost never been the actual
solution when this message comes up.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
