On 24/07/10 01:28, Robert Haas wrote: > Well, if we could change the backends so that they could fully > reinitialize themselves (disconnect from a database to which they are > bound, etc.), I don't see why we couldn't use the Apache approach. This would offer the bonus on the side that it'd be more practical to implement database changes for a connection, akin to MySQL's "USE". Inefficient, sure, but possible. I don't care about that current limitation very much. I think anyone changing databases all the time probably has the wrong design and should be using schema. I'm sure there are times it'd be good to be able to switch databases on one connection, though. My question with all this remains: is it worth the effort when external poolers already solve the problem. Can PostgreSQL offer tools and interfaces to permit external poolers to solve the problems they have, rather than trying to bring them in-core? For example, with auth, can the Pg server offer features to help poolers implement passthrough authentication against the real Pg server? Perhaps Pg could expose auth features over SQL, permitting appropriately privileged users to verify credentials with SQL-level calls. Poolers could pass supplied user credentials through to the real Pg server for verification. For bonus points, an SQL interface could be provided that lets the super-priveleged auth managing connection be used to change the login role of another running backend/connection, so the pooler could hand out connections with different login user ids without having to maintain a pool per user id. ( That'd probably also permit implementation of a "CHANGE USER" command, where the client changed login roles on the fly by passing the credentials of the new role. That'd be *awesome* for application server connection pools. ) -- Craig Ringer -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
