Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> 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.