Re: Prepared Statements vs. pgbouncer
От | Paul Lindner |
---|---|
Тема | Re: Prepared Statements vs. pgbouncer |
Дата | |
Msg-id | 20071001213237.GR3140@inuus.com обсуждение исходный текст |
Ответ на | Re: Prepared Statements vs. pgbouncer (Oliver Jowett <oliver@opencloud.com>) |
Ответы |
Re: Prepared Statements vs. pgbouncer
Re: Prepared Statements vs. pgbouncer |
Список | pgsql-jdbc |
On Tue, Oct 02, 2007 at 10:06:50AM +1300, Oliver Jowett wrote: > Paul Lindner wrote: > > >The problem is that the described solution puts way too much moving > >parts inside of something that should be very simple. You'd have to > >recreate most of Postgresql's parsing and grammar inside of Pgbouncer > >and change it from something simple into a full-featured proxy. > > What? Why on earth would you need to recreate the SQL grammar inside > pgbouncer?! Justify this. Eh? I didn't mention Sql grammar. A proxy would at minimum have to track and maintain connection settings and portals and recreate them on each backend. However a full-featured proxy could parse any GUC statements. In fact if you want full support for temporary tables (iffy) / temporary views (perhaps possible) and whatnot you will have to parse the SQL flying across the wire so you can recreate the session in it's entirety. Of course, I don't want nor need that. For the record: Please please please note that I'm only trying to solve a particular problem here. I know what I want to do is messy, ugly and a little impure and flies in the face of elegant design. If it helps think of what I'm proposing as akin to denormalization of a beautiful schema to achieve specific goals. -- Paul Lindner ||||| | | | | | | | | | lindner@inuus.com
Вложения
В списке pgsql-jdbc по дате отправления: