PL/Python result object str handler

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.

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/

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

On 1/8/13 4:32 AM, Magnus Hagander wrote:
> 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 don't think so. Any number you pick will be too low for someone.
Since this would only be executed when explicitly asked for, it's up to
the user to manage this. It's analogous to print(long_list) -- you
wouldn't truncate that.

On Tue, Jan 8, 2013 at 10:23 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On 1/8/13 4:32 AM, Magnus Hagander wrote:
>> 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 don't think so. Any number you pick will be too low for someone.
> Since this would only be executed when explicitly asked for, it's up to
> the user to manage this. It's analogous to print(long_list) -- you
> wouldn't truncate that.

Fair enough. I was thinking of a specific example when I wrote that,
bu I can't recall what it was, and clearly using print or the python
console would be the most similar scenarios. And they both do it the
way you suggest. So that's probably the right thing to do.

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

On 1/8/13 11:55 AM, Daniele Varrazzo wrote:
>>> <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).

The repr style was the only guideline I found. There is no guideline
for how str should look like when it's not repr. Do you have a better
suggestion for the output format?

(The reason this is str and not repr is that it doesn't contain other
information such as the tuple descriptor, so str of two different
results could easily be the same.)

On 13-01-07 09:58 PM, Peter Eisentraut wrote:
> 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.
>

Here is a review:

This patch adds a function that pl/python functions can call to convert
a query result hash into a string suitable for debug purposes. The use
case for this feature is primarily for debugging and logging purposes.
I feel that this is useful since a lot of debugging of stored functions
is usually done with print/elog style debugging.

There already some discussion on the thread as if the number of rows
printed should be limited, the consensus seemed to be 'no' since someone
would be unhappy with any limit and printing everything is the same
behaviour you get with the standard python print.

I've tested this with python2.6 and 3.1 and it seems to work as described.

I've looked through the code and everything looks fine.

The patch includes no documentation. Adding a few lines to the
"Utility Functions" section of the plpython documentation so people know
about this feature would be good.

Other than that I think it is fine to commit. I am setting this as
ready for committer, I assume you'll commit this yourself and that you
can add a paragraph to the docs as you commit it.

Steve

>
>

On Sat, 2013-02-02 at 15:43 -0500, Steve Singer wrote:
> I've looked through the code and everything looks fine.
>
> The patch includes no documentation. Adding a few lines to the
> "Utility Functions" section of the plpython documentation so people know
> about this feature would be good.

Added some documentation and committed. Thanks.