On 10/30/09, Peter Eisentraut <pete...@gmx.net> wrote:
> Calling PL/Python's elog functions exposes some curious behavior. For
> example, calling plpy.error('foo') prints
>
> ERROR: ('foo',)
>
> (instead of the
>
> ERROR: foo
>
> that one might have hoped for.) This is an implementation artifact,
> because those functions don't check their arguments, just take them as a
> tuple, convert the tuple to a string, and a singleton tuples look like
> the above as a string.
>
> The simple way to amend this is to force these functions to take exactly
> one argument print that. If people then actually want to pass a tuple,
> they should form one explicitly. This approach might break user's
> applications, however, if they have felt free to write things like
> plpy.error('error code', n). Although passing more than one argument is
> not documented, so arguably it can't be expected to work.
>
> Other ways to fix this would be: Check if the number of arguments is
> one. If yes, print that; else print the whole tuple. Or perhaps loop
> through all the arguments and explicitly print each separated by a
> comma.
>
> Comments?
I vote for handling tuple with 1 element better, otherwise keep old
behaviour.
I don't think breaking multi-arg calls is good idea, as they may be used
only in special situations. OTOH, it does not seem worthwhile to
spend effort trying to handle them better.
--
marko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
