Skip site navigation (1) Skip section navigation (2)

Re: PL/Python result object str handler

From: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PL/Python result object str handler
Date: 2013-01-08 16:55:58
Message-ID: CA+mi_8ayO-=SxX2v3+iNJ2WQZ=mp=gMQwCwJoVRMR1qNXrihCQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Jan 8, 2013 at 9:32 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Tue, Jan 8, 2013 at 3:58 AM, Peter Eisentraut <peter_e(at)gmx(dot)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


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2013-01-08 18:08:44
Subject: pg_upgrade regression test litters the source tree with log files
Previous:From: Tom LaneDate: 2013-01-08 15:39:25
Subject: Weird Assert failure in GetLockStatusData()

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group