On fre, 2012-02-10 at 17:44 +0100, Jean-Baptiste Quenot wrote:
Dear hackers,
Thanks for the work on PLPython result metadata, it is very useful! I
just came across a crash when trying to access this metadata on the
result of an UPDATE, which obviously cannot return any tuple (unless
you
On tor, 2012-04-05 at 19:49 +0200, Jean-Baptiste Quenot wrote:
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
On lör, 2012-03-24 at 16:24 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.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
2012/4/5 Peter Eisentraut pete...@gmx.net
On lör, 2012-03-24 at 16:24 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.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
Peter Eisentraut pete...@gmx.net writes:
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
On ons, 2012-03-07 at 17:14 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.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
Peter Eisentraut pete...@gmx.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
On lör, 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
Peter Eisentraut pete...@gmx.net writes:
On lör, 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
On ons, 2012-03-07 at 15:59 -0500, Tom Lane wrote:
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
Peter Eisentraut pete...@gmx.net writes:
On ons, 2012-03-07 at 15:59 -0500, Tom Lane wrote:
Or are we talking about two different things?
I think so. I'm wondering here how to detect whether the execution of a
statement has yielded a result set at all. (For example, you ran SELECT
or
On ons, 2012-03-07 at 16:49 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On ons, 2012-03-07 at 15:59 -0500, Tom Lane wrote:
Or are we talking about two different things?
I think so. I'm wondering here how to detect whether the execution of a
statement has yielded a
Peter Eisentraut pete...@gmx.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
2012/2/24 Peter Eisentraut pete...@gmx.net:
On fre, 2012-02-10 at 17:44 +0100, Jean-Baptiste Quenot wrote:
Please find attached a patch that solves this issue. Instead of a PG
crash, we get the following message:
ERROR: plpy.Error: no result fetched
Hmm, should it be an error or just
On fre, 2012-02-10 at 17:44 +0100, Jean-Baptiste Quenot wrote:
Thanks for the work on PLPython result metadata, it is very useful! I
just came across a crash when trying to access this metadata on the
result of an UPDATE, which obviously cannot return any tuple (unless
you specify a RETURNING
Dear hackers,
Thanks for the work on PLPython result metadata, it is very useful! I
just came across a crash when trying to access this metadata on the
result of an UPDATE, which obviously cannot return any tuple (unless
you specify a RETURNING clause maybe?).
Please find attached a patch that
16 matches
Mail list logo
