On Mon, Sep 10, 2012 at 9:59 AM, Josh Berkus <j...@agliodbs.com> wrote: > >> The point of the proposal that I am making is to have a simple, >> low-maintenance solution for people who need a single-application >> database. A compromise somewhere in the middle isn't likely to be an >> improvement for anybody. For instance, if you want to have additional >> connections, you open up a whole collection of communication and >> authentication issues, which potential users of a single-application >> database don't want to cope with. > > Yes, exactly. > > In fact, most of the folks who would want an embedded PostgreSQL either > want no authentication at all, or only a single password. So supporting > authentication options other than trust or md5 is not required, or > desired AFAIK.
I agree people who want embedded postgres probably want no authentication. For the sake of test/local development use cases, I still question the usefulness of a quasi-embeddable mode that does not support multiple executors as SQLite does -- it's pretty murderous for the testing use case for a number of people if they intend to have parity with their production environment. I could see this being useful for, say, iOS (although there is a definite chance that one will want to use multiple threads/simultaneous xacts in applications), or a network router, except that pg_xlog and the catalog are rather enormous for those use cases. So while the embedded use case is really appealing in general, I'm still intuitively quite skeptical of the omission of multi-executor support, especially considering that people have gotten used to being able to that with the incredibly popular SQLite. Could EXEC_BACKEND be repurposed -- even on *nix-- to make this work someday? -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
