Re: plpython does not honour max-rows

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kieran McCusker <kieran(dot)mccusker(at)gmail(dot)com>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: plpython does not honour max-rows
Date: 2023-05-02 14:02:30
Message-ID: 2678018.1683036150@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Kieran McCusker <kieran(dot)mccusker(at)gmail(dot)com> writes:
> Without making too much of a fuss, wouldn't it be simpler to honour a
> row-limit of zero rather than document that it doesn't work?

plpy.execute is a thin wrapper around SPI_execute, which does document
this point:

If <parameter>count</parameter> is zero then the command is executed
for all rows that it applies to. If <parameter>count</parameter>
is greater than zero, then no more than <parameter>count</parameter> rows
will be retrieved; execution stops when the count is reached, much like
adding a <literal>LIMIT</literal> clause to the query.

Since that's stood for a few decades now, changing it seems impossible
from the backwards-compatibility standpoint. However, it does seem
appropriate to repeat that material in the wrapper's documentation.

I wonder whether the similar plperl and pltcl wrappers are also
documentation-shy here.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2023-05-02 16:29:21 Re: BUG #17906: Segmentation fault and database crash during procedure call
Previous Message Daniel Gustafsson 2023-05-02 13:33:44 Re: Memory leak on subquery as scalar operand