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

2012/4/5 Peter Eisentraut <peter_e(at)gmx(dot)net>

> On lör, 2012-03-24 at 16:24 -0400, Tom Lane wrote:
> > Peter Eisentraut <peter_e(at)gmx(dot)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.
>
> Well, scratch that.
>
> 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