From: Tom Lane <tgl@sss.pgh.pa.us>
To: Marc Bachmann <marc.brookman@gmail.com>
cc: Robert Haas <robertmhaas@gmail.com>, jeremy@musicsmith.net,
        PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #16040: PL/PGSQL RETURN QUERY statement never uses a parallel
 plan
In-reply-to: <1F2F75F0-27DF-406F-848D-8B50C7EEF06A@gmail.com>
References: <16040-eaacad11fecfb198@postgresql.org>
 <1741.1584847383@sss.pgh.pa.us>
 <CA+TgmoZvR9SP5mzH1k7MYrv3y1z4dWoJGz2z2SU-Qo1B7LrdgA@mail.gmail.com>
 <1F2F75F0-27DF-406F-848D-8B50C7EEF06A@gmail.com>
Comments: In-reply-to Marc Bachmann <marc.brookman@gmail.com>
	message dated "Sun, 03 Oct 2021 04:20:17 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3735892.1633232886.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 02 Oct 2021 23:48:06 -0400
Message-ID: <3735893.1633232886@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3735893.1633232886%40sss.pgh.pa.us>
Precedence: bulk

Marc Bachmann <marc.brookman@gmail.com> writes:
> A function that inserts data and tries to return with a table now result=
s in the error `query is not a SELECT`.
> In previous versions that query succeeded.

Hmm ... I'm a bit surprised that that worked before, but since it did,
we shouldn't break it.  It looks like this was an accidental side-effect
of refactoring rather than something intentional.  Will look closer
tomorrow or so.

			regards, tom lane