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.
|
Список | 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 по дате отправления: