From: | Jean-Baptiste Quenot <jbq(at)caraldi(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Fix PL/Python metadata when there is no result |
Date: | 2012-04-05 17:49:44 |
Message-ID: | CAK6bCawJpcomxw-SLumYoZHWF12=3xuVM=xPpGm+Vb5B5NOmqQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-04-05 17:54:39 | Re: Fix PL/Python metadata when there is no result |
Previous Message | Peter Eisentraut | 2012-04-05 17:33:25 | Re: Fix PL/Python metadata when there is no result |