On ons, 2012-03-07 at 16:49 -0500, Tom Lane wrote: > Peter Eisentraut <pete...@gmx.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? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
