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
> y
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 pro
Peter Eisentraut 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 latter, becau
2012/4/5 Peter Eisentraut
> On lör, 2012-03-24 at 16:24 -0400, Tom Lane wrote:
> > Peter Eisentraut 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() mi
On lör, 2012-03-24 at 16:24 -0400, Tom Lane wrote:
> Peter Eisentraut 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
Peter Eisentraut 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
On ons, 2012-03-07 at 17:14 -0500, Tom Lane wrote:
> Peter Eisentraut 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 an
Peter Eisentraut 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 we
On ons, 2012-03-07 at 16:49 -0500, Tom Lane wrote:
> Peter Eisentraut 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
Peter Eisentraut 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 INSERT ... RETU
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 result
Peter Eisentraut 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 expected
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 expec
2012/2/24 Peter Eisentraut :
> 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 return
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 RETURN
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 s
16 matches
Mail list logo
