Re: Prepared Statements vs. pgbouncer

Paul Lindner wrote:
> On Tue, Oct 02, 2007 at 10:06:50AM +1300, Oliver Jowett wrote:
>> Paul Lindner wrote:
>> You'd have to recreate most of Postgresql's parsing and grammar inside of Pgbouncer

>> What? Why on earth would you need to recreate the SQL grammar inside
>> pgbouncer?! Justify this.
>
> Eh? I didn't mention Sql grammar.

Sorry if I misinterpreted what "most of Postgresql's parsing and
grammar" meant then.

> 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.

I can think of a few ways around this offhand that don't require parsing
every statement going past (e.g. SHOW ALL, or individual SHOWs on the
subset of GUCs you care about, when considering whether to move a
connection). Even if you do have to inspect queries you hardly need a
full-blown lexer/parser to recognize SET, the syntax is fairly simple.

> 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.

I think it's acceptable to put some limits on what *application level*
SQL can do when running through pgbouncer, document that temporary
tables that are not ON COMMIT DROP aren't supported or whatever. You
could do the same for SET SESSION if you really wanted.

But the application usually can't do anything about the protocol level
stuff, so you pretty much have to get that right. Currently pgbouncer
does not do this.

-O