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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CALL stmt, ERROR: unrecognized node type: 113 bug
Date: 2018-02-13 08:57:34
Message-ID: 20180213085734.GA1026@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marina Polyakova 2018-02-13 10:40:46 master plpython check fails on Solaris 10
Previous Message Amit Langote 2018-02-13 08:47:43 reorganizing partitioning code (was: Re: [HACKERS] path toward faster partition pruning)