> > webclient <---> proxy <---> Postgres > >Ok. Pluses: > >- The standalone program is easier to hack together than delving into the > database I could probably just hack on SQL Relay or something. >- The proxy can be as tightly secured as the database without losing > functionallity, as it only needs to accept a connection from the secure > web server. > >Minuses: > >- Another machine to buy >- Root on the proxy is as bad as root was on the secure server, so.. >- The simple hack will need thorough security auditing >- It's yet another machine to secure. >- It's yet another point of failure. If you're not too afraid you could try running the proxy server on the database. Check out Perl's DBD Proxy and Server. I believe you can use it to limit the sort of queries that go through. In fact you could probably use it write a proxy which only does a handful of queries - where the SQL is prestored/hardcoded in the proxy, so in effect all the client can supply are the parameters. Now, the question is - would the DBD proxy be fast, robust and safe enough for you... Also another issue is you will probably need to use perl at the relevant webapps- the client (webapp) will use DBD proxy to talk to DBD server which will then talk to the actual database. Cheerio, Link.