Re: CALL stmt, ERROR: unrecognized node type: 113 bug - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: CALL stmt, ERROR: unrecognized node type: 113 bug
Date
Msg-id 20180213085734.GA1026@paquier.xyz
Whole thread Raw
In response to Re: CALL stmt, ERROR: unrecognized node type: 113 bug  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: CALL stmt, ERROR: unrecognized node type: 113 bug  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On Mon, Feb 12, 2018 at 03:19:27PM -0500, Tom Lane wrote:
> I've not read in detail, but it looks reasonable offhand, modulo
> that I still don't like prorettype == 0 ;-).
>
> I did notice a tiny typo:
>
> -     * with.  Hence prefer "$function$", but extend if needed.
> +     * with.  Hence prefer "$function$"/"$procedure", but extend if needed.
>
> I think you want
>
> +     * with.  Hence prefer "$function$"/"$procedure$", but extend if needed.

0001 and 0002 are welcome.  I have a small comment on top of Tom's for 0003.

+   appendStringInfoString(&buf, ")\n");
+   if (proc->prorettype)
+   {
+       appendStringInfoString(&buf, " RETURNS ");
+       print_function_rettype(&buf, proctup);
+       appendStringInfoChar(&buf, '\n');
+   }
Could you use a separate boolean variable which is set as
OidIsValid(prorettype), say called isfunction?  The goal is to avoid the
check on prorettype in more than one place.  If pg_proc's shape is
changed depending on the discussion, the current patch is a recipy to
forget updating all those places.  A comment in pg_get_function_result
to mention that prorettype = InvalidOid is here to track that the call
involves a procedure would be nice.

Should the documentation of pg_function_is_visible also mention
procedures?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: reorganizing partitioning code (was: Re: [HACKERS] path toward fasterpartition pruning)
Next
From: Marina Polyakova
Date:
Subject: master plpython check fails on Solaris 10