Re: Prepared Statements vs. pgbouncer - Mailing list pgsql-jdbc

From Paul Lindner
Subject Re: Prepared Statements vs. pgbouncer
Date
Msg-id 20071001213237.GR3140@inuus.com
Whole thread Raw
In response to Re: Prepared Statements vs. pgbouncer  (Oliver Jowett <oliver@opencloud.com>)
Responses Re: Prepared Statements vs. pgbouncer
Re: Prepared Statements vs. pgbouncer
List 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

Attachment

pgsql-jdbc by date:

Previous
From: Oliver Jowett
Date:
Subject: Re: Prepared Statements vs. pgbouncer
Next
From: Oliver Jowett
Date:
Subject: Re: Prepared Statements vs. pgbouncer