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

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-24 18:48:06
Message-ID: 1332614886.15083.8.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On ons, 2012-03-07 at 17:14 -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > On ons, 2012-03-07 at 16:49 -0500, Tom Lane wrote:
> >> 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?
>
> 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.

It turns out I was mistaken about the .nrows() behavior. It returns 0
even for utility commands, because the value comes straight from
SPI_processed. But SPI_processed is a C variable, which can't have a
"not applicable" value, so that doesn't necessarily mean other languages
can't handle this differently.

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. Then the
programming style would be "if there are rows, give me metadata about
them".

The alternative would be to introduce another function "has_rows" or
something, but then how would that be more intuitive than saying
"nrows() is not None"?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua Berkus 2012-03-24 20:12:50 Re: Gsoc2012 Idea --- Social Network database schema
Previous Message Michael Tautschnig 2012-03-24 17:01:32 Re: Weak-memory specific problem in ResetLatch/WaitLatch (follow-up analysis)