On Wed, Sep 5, 2012 at 7:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > This seems to me to be going in exactly the wrong direction. What > I visualize this feature as responding to is demand for a *simple*, > minimal configuration, minimal administration, quasi-embedded database. > What you propose above is not that, but is if anything even more > complicated for an application to deal with than a regular persistent > server. More complication is *the wrong thing* for this use case. > > The people who would be interested in this are currently using something > like SQLite within a single application program. It hasn't got any of > the features you're suggesting either, and I don't think anybody wishes > it did.
I am failing to understand how one could easily replicate the SQLite feature of (even fairly poorly) using multiple processes addressing one database, and supporting multiple executors per-database (which correspond to every open 'connection' in SQLite, as far as I can understand). My best thoughts are in the direction of EXEC_BACKEND and hooking up to a cluster post-facto, but I wasn't really looking for solutions so much as to raise this (to me) important use-case. I'm just thinking about all the enormously popular prefork based web servers out there like unicorn (Ruby), gunicorn (Python), and even without forking language-specific database abstractions like that seen in Go ("database/sql") that have decided to make pooling the default interaction. It is easiest to use these prefork embedded servers in both in development and production, so people (rather sensibly) do that -- better parity, and no fuss. I really would rather not see that regress by appropriating special mechanics for test/development scenarios with regards to managing database connections (e.g. exactly one of them), so how do we not make that a restriction, unless I misunderstood and was a non-restriction already? -- fdr -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers