2012/4/5 Peter Eisentraut
<peter_e@gmx.net>On lör, 2012-03-24 at 16:24 -0400, Tom Lane wrote:
> Peter Eisentraut <
peter_e@gmx.net> writes:
> > On ons, 2012-03-07 at 17:14 -0500, Tom Lane wrote:
> >> I said it was a reasonable alternative, not that it was the only one
> >> we should consider. The behavior of .nrows() might be accidental,
> >> but perhaps it is a preferable model to adopt.
>
> > After pondering this for several days now I still think the best
> > approach is to change .nrows() to return None for utility commands and
> > have the other metadata functions throw exceptions.
>
> OK, I don't have strong feelings about it.
This whole area is sloppily documented. resultset.nrows() returns
SPI_processed, which is the number of rows, er, processed by the
statement, which may or may not be the number of rows returned. So a
statement that returns no result set could very well have nrows() > 0.
The number of rows returned can be obtained by using len(resultset) (not
documented, but one could perhaps guess it). But len() cannot return
None, so we cannot use that as a marker.
The alternatives are now to introduce a new function like has_rows()
that returns True iff result rows exist and therefore result metadata
can be fetched, or go back to having coltypes() et al. return None when
no metadata exists. I'm in favor of the latter, because the former
would add somewhat needless complications and doesn't really add any
robustness or the like.
I consider that this is an error to request metadata when the query does not return some. For example: "UPDATE mytable SET value = 1" does not return column metadata, so user is not supposed to col coltypes(). That's why I propose to return an error. coltypes() is supposed to return a sequence, not None. Checking for None is a bad coding practise IMO, especially when dealing with lists.
But anyway, returning None or raising an error is still much better than crashing :-)
Cheers,
--
Jean-Baptiste Quenot
