Re: embedded/"serverless" (Re: serverless postgresql)
От | Rick Gigger |
---|---|
Тема | Re: embedded/"serverless" (Re: serverless postgresql) |
Дата | |
Msg-id | 002f01c3e122$f2764240$0700a8c0@trogdor обсуждение исходный текст |
Ответ на | Re: embedded/"serverless" (Re: serverless postgresql) ("Chris Ochs" <chris@paymentonline.com>) |
Ответы |
Re: embedded/"serverless" (Re: serverless postgresql)
|
Список | pgsql-general |
> "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?
В списке pgsql-general по дате отправления: