Re: Avoiding bad prepared-statement plans.

Поиск
Список
Период
Сортировка
От Pierre C
Тема Re: Avoiding bad prepared-statement plans.
Дата
Msg-id op.u8caiphxeorkce@localhost
обсуждение исходный текст
Ответ на Re: Avoiding bad prepared-statement plans.  (Dimitri Fontaine <dfontaine@hi-media.com>)
Ответы Re: Avoiding bad prepared-statement plans.
Re: Avoiding bad prepared-statement plans.
Список pgsql-hackers
> What about catching the error in the application and INSERT'ing into the
> current preprepare.relation table? The aim would be to do that in dev or
> in pre-prod environments, then copy the table content in production.

Yep, but it's a bit awkward and time-consuming, and not quite suited to  
ORM-generated requests since you got to generate all the plan names, when  
the SQL query itself would be the most convenient "unique identifier"...

A cool hack would be something like that :

pg_execute( "SELECT ...", arguments... )

By inserting a hook which calls a user-specified function on non-existing  
plan instead of raising an error, this could work.
However, this wouldn't work as-is since the plan name must be <=  
NAMEDATALEN, but you get the idea ;)


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: A thought: should we run pgindent now?
Следующее
От: "Greg Sabino Mullane"
Дата:
Сообщение: Re: Listen/Notify payload and interfaces