Re: Avoiding bad prepared-statement plans.

Поиск
Список
Период
Сортировка
От David Christensen
Тема Re: Avoiding bad prepared-statement plans.
Дата
Msg-id B2AD690B-D9B4-4D42-94AD-9D11CAE5DD03@endpoint.com
обсуждение исходный текст
Ответ на Re: Avoiding bad prepared-statement plans.  ("Pierre C" <lists@peufeu.com>)
Ответы Re: Avoiding bad prepared-statement plans.  (Kenneth Marshall <ktm@rice.edu>)
Список pgsql-hackers
On Feb 18, 2010, at 2:19 PM, Pierre C wrote:

>
>> 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 ;)

How about the SHA1 hash of the query?  Hey, it works for git... :-)

Regards,

David
--
David Christensen
End Point Corporation
david@endpoint.com






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

Предыдущее
От: Euler Taveira de Oliveira
Дата:
Сообщение: Re: PGXS: REGRESS_OPTS=--load-language=plpgsql
Следующее
От: David Fetter
Дата:
Сообщение: Re: PGXS: REGRESS_OPTS=--load-language=plpgsql