Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan
Дата
Msg-id CAFj8pRDSDnv5n+ZnJTx21x1MdEzXBTmoE45xGeUy1gQFfGtF6g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers


2017-09-08 23:09 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:
Pavel Stehule <pavel.stehule@gmail.com> writes:
> personally I prefer syntax without FOR keyword - because following keyword
> must be reserved keyword

> SET x = .., y = .. SELECT ... ;

Nope.  Most of the statement-starting keywords are *not* fully reserved;
they don't need to be as long as they lead off the statement.  But this
proposal would break that.  We need to put FOR or IN or another
already-fully-reserved keyword after the SET list, or something's going
to bite us.

the possibility to control plan cache for any command via GUC outside PLpgSQL can introduce lot of question.

What impact will be on PREPARE command and on EXECUTE command?

If we disable plan cache for EXECUTE, should we remove plan from plan cache? ...

Can we have some diagnostic to get info if some command has cached plan or not? 

Regards

Pavel
  

                        regards, tom lane

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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] Setting pd_lower in GIN metapage
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: [HACKERS] pgbench more operators & functions