Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1ptqdW-0004dV-Cy
	for pgsql-bugs@arkaria.postgresql.org; Tue, 02 May 2023 14:05:46 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1ptqdU-0004yO-DM
	for pgsql-bugs@arkaria.postgresql.org; Tue, 02 May 2023 14:05:44 +0000
Received: from makus.postgresql.org ([2001:4800:3e1:1::229])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1ptqaV-0000zw-9O
	for pgsql-bugs@lists.postgresql.org; Tue, 02 May 2023 14:02:39 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by makus.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1ptqaP-00088p-7Q
	for pgsql-bugs@lists.postgresql.org; Tue, 02 May 2023 14:02:38 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 342E2UMx2678019;
	Tue, 2 May 2023 10:02:30 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kieran McCusker <kieran.mccusker@gmail.com>
cc: Daniel Gustafsson <daniel@yesql.se>, pgsql-bugs@lists.postgresql.org
Subject: Re: plpython does not honour max-rows
In-reply-to: 
 <CAGgUQ6FMfBrCTeu7DLUmmsSVn0zu02mx7xZ39etb26pAqTrM+w@mail.gmail.com>
References: 
 <CAGgUQ6H6qYScctOhktQ9HLFDDoafBKHyUgJbZ6q_dOApnzNTXg@mail.gmail.com>
 <711512C7-2BC2-4901-A368-6A5A23023F72@yesql.se>
 <CAGgUQ6GBpw-vkzxuuTk3au8Hq+YezG5sv3yR=YjE3CbOqp-a3Q@mail.gmail.com>
 <D2132F23-B3AF-4D98-9859-BC2B64A599EC@yesql.se>
 <CAGgUQ6FMfBrCTeu7DLUmmsSVn0zu02mx7xZ39etb26pAqTrM+w@mail.gmail.com>
Comments: In-reply-to Kieran McCusker <kieran.mccusker@gmail.com>
	message dated "Tue, 02 May 2023 12:51:06 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2678017.1683036150.1@sss.pgh.pa.us>
Date: Tue, 02 May 2023 10:02:30 -0400
Message-ID: <2678018.1683036150@sss.pgh.pa.us>
List-Id: <pgsql-bugs.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-bugs@lists.postgresql.org>
List-Owner: <mailto:pgsql-bugs-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-bugs>
Archived-At: 
 <https://www.postgresql.org/message-id/2678018.1683036150%40sss.pgh.pa.us>
Precedence: bulk

Kieran McCusker <kieran.mccusker@gmail.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