Horton

Re: CALL stmt, ERROR: unrecognized node type: 113 bug

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, "David G. Johnston" <david.g.johnston@gmail.com>, Pavel Stehule <pavel.stehule@gmail.com>, Postgres hackers <pgsql-hackers@postgresql.org>, Andrew Dunstan <andrew@dunslane.net>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Date: 2018-02-10T23:17:55Z
Lists: pgsql-hackers 
On Sat, Feb 10, 2018 at 01:46:40PM -0500, Tom Lane wrote:
> I pushed a fix for all that.

Shouldn't there be a test case as well?  The patch I sent upthread was
doing the whole set, except that I did not bother 

> The failure in pg_get_functiondef() is still there.  While the immediate
> answer probably is to teach that function to emit correct CREATE PROCEDURE
> syntax, I continue to think that it's a bad idea to be putting zeroes into
> pg_proc.prorettype.

Yeah, or an error with a new function dedicated to procedures.  I also
finc confusing the use of prorettype to track this object type.

This brings the amount of objects stored in pg_proc to four.  Perhaps it
would be time to bring more clarity in pg_proc by introducing a prokind
column for functions, aggregates, window functions and procedures?  I
don't feel really hot for an extra boolean column like proisproc.
--
Michael

Commits

  1. Avoid premature free of pass-by-reference CALL arguments.

  2. Fix oversight in CALL argument handling, and do some minor cleanup.