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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-01-08 18:08:44 | pg_upgrade regression test litters the source tree with log files |
Previous Message | Tom Lane | 2013-01-08 15:39:25 | Weird Assert failure in GetLockStatusData() |