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