Horton

Re: Extending outfuncs support to utility statements

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org, Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Date: 2022-07-11T00:28:44Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> On 2022-07-10 19:12:52 -0400, Tom Lane wrote:
>> They're not so much "cold" as "dead", so I don't see the point
>> of having them at all.  If we ever start allowing utility commands
>> (besides NOTIFY) in stored rules, we'd need readfuncs support then
>> ... but at least in the short run I don't see that happening.

> It would allow us to test utility outfuncs as part of the
> WRITE_READ_PARSE_PLAN_TREES check. Not that that's worth very much.

Especially now that those are all auto-generated anyway.

> I guess it could be a minor help in making a few more utility commands benefit
> from paralellism?

Again, once we have an actual use-case, enabling that code will be
fine by me.  But we don't yet.

			regards, tom lane

Commits

  1. Avoid copying undefined data in _readA_Const().

  2. Enable WRITE_READ_PARSE_PLAN_TREES of rewritten utility statements

  3. Implement WRITE_READ_PARSE_PLAN_TREES for raw parse trees

  4. Don't lose precision for float fields of Nodes.

  5. Fix write/read of empty string fields in Nodes.

  6. Add read support for some missing raw parse nodes

  7. Fix reading of BitString nodes

  8. Fix reading of most-negative integer value nodes