Re: DEALLOCATE ALL

Поиск
Список
Период
Сортировка
Искать
От
Neil Conway
Тема
Re: DEALLOCATE ALL
Дата
Msg-id
460C400C.8040007@samurai.com
Ответ на
DEALLOCATE ALL (Marko Kreen)
Список
Дерево обсуждения
DEALLOCATE ALL "Marko Kreen" <markokr@gmail.com>
Re: DEALLOCATE ALL Alvaro Herrera <alvherre@alvh.no-ip.org>
Re: DEALLOCATE ALL Tom Lane <tgl@sss.pgh.pa.us>
Re: DEALLOCATE ALL "Marko Kreen" <markokr@gmail.com>
Re: DEALLOCATE ALL Bruce Momjian <bruce@momjian.us>
Re: DEALLOCATE ALL Neil Conway <neilc@samurai.com>
Re: DEALLOCATE ALL Alvaro Herrera <alvherre@commandprompt.com>
Re: DEALLOCATE ALL "Marko Kreen" <markokr@gmail.com>
Re: DEALLOCATE ALL Alvaro Herrera <alvherre@commandprompt.com>
Re: DEALLOCATE ALL "Marko Kreen" <markokr@gmail.com>
Re: DEALLOCATE ALL Alvaro Herrera <alvherre@commandprompt.com>
Re: DEALLOCATE ALL Heikki Linnakangas <heikki@enterprisedb.com>
Marko Kreen wrote:
> When pooling connections where prepared statements are in use,
> it is hard to give new client totally clean connection as
> there may be allocated statements that give errors when
> new client starts preparing statements again.

I agree with the other comments that RESET SESSION is the right API for 
this, although we can also provide DEALLOCATE ALL, I suppose.

As to the implementation, calling hash_remove() in a loop seems a pretty 
unfortunate way to clear a hash table -- adding a hash_reset() function 
to the dynahash API would be cleaner and faster.

-Neil

В списке pgsql-patches по дате отправления
От: Bruce Momjian
Дата:
От: Bruce Momjian
Дата:
Сообщение: Re: Small code clean-up
FAQ