On Mon, Sep 10, 2012 at 9:59 AM, Josh Berkus <josh@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
