> "Rick Gigger" <rick@alpinenetworking.com> writes:
> >> All of this explains why an embedded PostgreSQL isn't a great idea. It
> >> being a true multi-user database means that even if you went though
> >> all the work needed to turn it into an embedded database you wouldn't
> >> get most of the advantages.
>
> > Is it true that postgres is not suited for this and should not be used
as
> > such or is it just a matter of spending the time to allow you maybe
compile
> > an embedded version?
>
> I think that Steve has it exactly right here. Postgres isn't designed
> to be an embedded database in that sense, and none of the developers are
> interested in moving it in that direction. It would require too many
> compromises versus the full-fledged-server situation.
>
> This is definitely a case where one size does not fit all. Rather
> than trying to force-fit Postgres to an application it's not suited for,
> you should use another product that is designed for that application.
> In short: your time would be better spent on upgrading SQLite to do what
> you need.
How about the following comment from an earlier post:
> Now, while I think that an embedded fork of PostgreSQL is completely
> missing the point I do think that a low maintenance fork or
> configuration option would be a very useful feature. I'd love to
> be able to ship an application that would
>
> o Have a private installation of PostgreSQL
>
> o That would run semi-persistently - if the DB isn't running, the
> application will transparently start it, and if the DB is idle
> for some length of time it gracefully shuts down
>
> o Is zero-maintenance - all vacuuming, analysing etc is handled
> automatically. So are database version upgrades.
>
> o That runs under the permissions of the user running the application
>
> o And that could, by tweaking an application configuration variable
> could swap out the private PostgreSQL installation and instead
> access a standard installation
Is this something that could make sense for postgres?