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

Re: PL/Python result object str handler

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PL/Python result object str handler
Date: 2013-01-08 09:32:40
Message-ID: CABUevEy8wiuO2uKz4BdaX12JSddokuSfxzE6dYE8moTgDBdsVg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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'}]>
>
> 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?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


In response to

Responses

pgsql-hackers by date

Next:From: 李海龙Date: 2013-01-08 10:48:50
Subject: Re: I s this a bug of spgist index in a heavy write condition?
Previous:From: Takeshi YamamuroDate: 2013-01-08 09:19:13
Subject: Re: Improve compression speeds in pg_lzcompress.c

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