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