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
Date: Mon, 11 Jul 2022 10:16:37 -0400
Message-ID: <1078368.1657548997@sss.pgh.pa.us> (raw)
In-Reply-To: <9b197806-17ee-acba-0e70-01263aa46e79@enterprisedb.com>
References: <4159834.1657405226@sss.pgh.pa.us>
<9b197806-17ee-acba-0e70-01263aa46e79@enterprisedb.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, peter.eisentraut@enterprisedb.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Extending outfuncs support to utility statements
In-Reply-To: <1078368.1657548997@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox