From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Extending outfuncs support to utility statements
In-reply-to: <9b197806-17ee-acba-0e70-01263aa46e79@enterprisedb.com>
References: <4159834.1657405226@sss.pgh.pa.us>
 <9b197806-17ee-acba-0e70-01263aa46e79@enterprisedb.com>
Comments: In-reply-to Peter Eisentraut <peter.eisentraut@enterprisedb.com>
	message dated "Mon, 11 Jul 2022 15:56:44 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1078367.1657548997.1@sss.pgh.pa.us>
Date: Mon, 11 Jul 2022 10:16:37 -0400
Message-ID: <1078368.1657548997@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1078368.1657548997%40sss.pgh.pa.us>
Precedence: bulk

Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> On 10.07.22 00:20, Tom Lane wrote:
>> We've long avoided building I/O support for utility-statement node
>> types, mainly because it didn't seem worth the trouble to write and
>> maintain such code by hand.
k
> This is also needed to be able to store utility statements in (unquoted) 
> SQL function bodies.  I have some in-progress code for that that I need 
> to dust off.  IIRC, there are still some nontrivial issues to work 
> through on the reading side.  I don't have a problem with enabling the 
> outfuncs side in the meantime.

Oh!  I'd not thought of that, but yes that is a plausible near-term
requirement for readfuncs support for utility statements.  So my
concern about suppressing those is largely a waste of effort.

There might be enough node types that are raw-parse-tree-only,
but not involved in utility statements, to make it worth
continuing to suppress readfuncs support for them.  But I kinda
doubt it.  I'll try to get some numbers later today.

			regards, tom lane