Re: xmlconcat as variadic function

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: xmlconcat as variadic function
Date: 2008-11-17 17:34:11
Message-ID: 4854.1226943251@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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. 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');

On the whole I think we should just leave it alone.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2008-11-17 17:37:40 Re: Pl/Perl function: Speed of the First time executing pl/perl function in connection;
Previous Message Andrew Dunstan 2008-11-17 17:31:55 Re: Pl/Perl function: Speed of the First time executing pl/perl function in connection;