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?
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 |