Re: Weird PL/Python elog output - Mailing list pgsql-hackers

From Marko Kreen
Subject Re: Weird PL/Python elog output
Date
Msg-id e51f66da0910300813l2f30b94bwaff0c2644cc8eb70@mail.gmail.com
Whole thread Raw
In response to Weird PL/Python elog output  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Weird PL/Python elog output  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On 10/30/09, Peter Eisentraut <peter_e@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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Patch for automated partitioning
Next
From: John Murtari
Date:
Subject: Patch set under development to add usage reporting.