Re: PL/Python result object str handler - Mailing list pgsql-hackers

From Daniele Varrazzo
Subject Re: PL/Python result object str handler
Date
Msg-id CA+mi_8ayO-=SxX2v3+iNJ2WQZ=mp=gMQwCwJoVRMR1qNXrihCQ@mail.gmail.com
Whole thread Raw
In response to Re: PL/Python result object str handler  (Magnus Hagander <magnus@hagander.net>)
Responses Re: PL/Python result object str handler
List pgsql-hackers
On Tue, Jan 8, 2013 at 9:32 AM, Magnus Hagander <magnus@hagander.net> wrote:
> On Tue, Jan 8, 2013 at 3:58 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
>> For debugging PL/Python functions, I'm often tempted to write something
>> like
>>
>> rv = plpy.execute(...)
>> plpy.info(rv)
>>
>> which prints something unhelpful like
>>
>> <PLyResult object at 0xb461d8d8>
>>
>> By implementing a "str" handler for the result object, it now prints
>> something like
>>
>> <PLyResult status=5 nrows=2 rows=[{'foo': 1, 'bar': '11'}, {'foo': 2, 'bar': '22'}]>

This looks more a repr-style format to me (if you implement repr but
not str, the latter will default to the former).


>> Patch attached for review.
>
> How does it work if there are many rows in there? Say the result
> contains 10,000 rows - will the string contain all of them? If so,
> might it be worthwhile to cap the number of rows shown and then follow
> with a "..." or something?

I think it would: old django versions were a pain in the neck because
when a page broke an entire dump of gigantic queries was often dumped
as debug info.

-- Daniele



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Weird Assert failure in GetLockStatusData()
Next
From: Tom Lane
Date:
Subject: pg_upgrade regression test litters the source tree with log files