Re: Weird PL/Python elog output

From: Marko Kreen <markokr(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Weird PL/Python elog output
Date: 2009-10-30 15:13:27
Message-ID: e51f66da0910300813l2f30b94bwaff0c2644cc8eb70@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/30/09, Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Murtari 2009-10-30 16:02:21 Patch set under development to add usage reporting.
Previous Message Peter Eisentraut 2009-10-30 15:04:01 Re: Patch for automated partitioning