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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
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-07 20:59:40
Message-ID: 19069.1331153980@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On lr, 2012-02-25 at 18:03 +0100, Jean-Baptiste Quenot wrote:
>> IMO raising an error is much better because:
>> 1) It is not a valid usecase to retrieve result metadata when no rows
>> are expected to be returned

> Which led me to think, how are you actually expected to know when no
> rows are expected to be returned, in PL/Python? You can look at
> result.status(), which returns a numeric SPI status, but that seems
> fragile. I notice that result.nrows() returns None when no rows are
> returned. Is that good enough? In that case, we should document that
> and then make the new functions throw exceptions like you suggest.

Wait a minute ... I don't understand why that's not a valid use-case.
I have seen more than one piece of code that does a SELECT ... LIMIT 0
or equivalent for the express purpose of finding out the rowtype
produced by a particular query. Why would we make it impossible to do
that in pl/python? Or are we talking about two different things?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2012-03-07 21:02:43 Re: patch for a locale-specific bug in regression tests (REL9_1_STABLE)
Previous Message Bruce Momjian 2012-03-07 20:56:21 Re: Checksums, state of play