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

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: CALL stmt, ERROR: unrecognized node type: 113 bug
Дата
Msg-id CAFj8pRBEAFZNeLCu0G6V_LvzkXGBOBAE8MPCoSu648t7V=EvrQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: CALL stmt, ERROR: unrecognized node type: 113 bug  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: CALL stmt, ERROR: unrecognized node type: 113 bug
Список pgsql-hackers
Hi

2018-02-09 7:56 GMT+01:00 Michael Paquier <michael@paquier.xyz>:
On Fri, Feb 02, 2018 at 04:07:28PM +0900, Michael Paquier wrote:
> You need to read that as "only a SubPlan can be executed after a SubLink
> has been processed by the planner", so please replace the last "latter"
> by "planner".

(I forgot to add Peter and Andrew in CC: previously, so done now.)

e4128ee7 is making is clear that SubLink are authorized when
transforming it in transformSubLink(), however I cannot think about a
use case so should we just forbid them, and this is actually untested.
So the patch attached does so.

The second problem involves a cache lookup failure for a type when
trying to use pg_get_functiondef on a procedure.  Luckily, it is
possible to make the difference between a procedure and a function by
checking if prorettype is InvalidOid or not.  There is room for a new
patch which supports pg_get_proceduredef() to generate the definition of
a procedure, with perhaps a dedicated psql shortcut, but that could
always be done later on.

Blocking subqueries in CALL parameters is possible solution. But blocking func def for procedures without any substitution doesn't look correct for me.

Regards

Pavel
 
--
Michael

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Marko Tiikkaja
Дата:
Сообщение: Re: Using scalar function as set-returning: bug or feature?
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: Using scalar function as set-returning: bug or feature?