Sean Chittenden <[EMAIL PROTECTED]> writes:
> it's very plausible to imagine a world where a backend hands an idle
> connection back to the parent process for safe keeping/process load
> balancing.
And your current database, user authorization, prepared statements,
SET values, cached plpgsql plans, etc etc go where exactly?
The notion that a Postgres session can be replaced by a lightweight
object is just not workable IMHO; we've developed far too many features
that require persistent state on the backend side.
For applications that don't need those features (or, more realistically,
want the same persistent state for all transactions they engage in),
client-side connection pooling solves the problem. It seems very
unlikely that apps that are too diverse to share a client-side pool
would be able to share a backend session if only the connection
mechanism were a bit different.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
