Weird PL/Python elog output

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Weird PL/Python elog output
Date: 2009-10-30 14:53:32
Message-ID: 1256914412.525.17.camel@fsopti579.F-Secure.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message pg 2009-10-30 15:03:21 Re: Syntax for partitioning
Previous Message Devrim GÜNDÜZ 2009-10-30 14:17:27 Re: Syntax for partitioning