Re: Extending outfuncs support to utility statements

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

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2022-07-12T22:38:26Z
Lists: pgsql-hackers
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> 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.

BTW, I experimented with trying to enable WRITE_READ_PARSE_PLAN_TREES
for utility statements, and found that the immediate problem is that
Constraint and a couple of other node types lack read functions
(they're the ones marked "custom_read_write, no_read" in parsenodes.h).
They have out functions, so writing the inverses seems like it's just
something nobody ever got around to.  Perhaps there are deeper problems
lurking behind that one, though.

			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