Re: Fix PL/Python metadata when there is no result

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jean-Baptiste Quenot <jbq(at)caraldi(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fix PL/Python metadata when there is no result
Date: 2012-03-07 21:59:46
Message-ID: 1331157586.12416.12.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On ons, 2012-03-07 at 16:49 -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > On ons, 2012-03-07 at 15:59 -0500, Tom Lane wrote:
> >> Or are we talking about two different things?
>
> > I think so. I'm wondering here how to detect whether the execution of a
> > statement has yielded a result set at all. (For example, you ran SELECT
> > or INSERT ... RETURNING, versus CREATE TABLE or VACUUM.)
>
> Got it. I agree that throwing an error for resultset property inquiries
> is reasonable in such cases, as long as there is some non-error-throwing
> way to test whether a resultset was returned or not.

Well, that's the question. The only two ways currently to find out
whether a result set was returned is by looking at .nrows(), which I
think works by accident, or at .status(), which is the SPI status code,
and that's quite cumbersome.

> Still, it seems rather arbitrary to say that the row count property is
> the thing to test for that purpose and no other is. Why not return None
> for any property that's not sensible?

Hmm, above you said you were in favor of throwing an error rather than
returning None?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-03-07 22:14:02 Re: Fix PL/Python metadata when there is no result
Previous Message Robert Haas 2012-03-07 21:59:37 Re: NULL's support in SP-GiST