All,
> > I don't care what people do with their data, especially if they're
> > using MySQL. What I am arguing against is adding something like this
> > proxy capability to Postgres.
>
> I agree on that point. I certainly wouldn't like to see anyone expend
> significant effort to make this work for Postgres.
I wasn't focussing on the auditing capabilities, although there's performance
tuning/troubleshooting reasons why auditing just the proxy would be useful.
I was thinking of scripting capabilities for a connection pooler in general.
Sort of like an iptables for PostgreSQL connections.
I don't know if MySQL proxy does this, but I can see how it would be useful
for large multi-application PostgreSQL installations. For example, you could
script the proxy to accept a certain number of connection errors over a
certain period of time and then switch automatically to the failover server,
maybe even dispatching slony commands in the process. Or to clamp down on
DOSes by simply discarding too many connections in too short a time. Or to
pass through all connections from a specific appserver to a test copy of the
database temporarily.
I think you get the idea. Mind you, this is hardly our #1 priority but it
would make a nice SoC project.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
