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
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 |