Re: Proof of concept: standalone backend with full FE/BE protocol
От | Tom Lane |
---|---|
Тема | Re: Proof of concept: standalone backend with full FE/BE protocol |
Дата | |
Msg-id | 20331.1346897676@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Proof of concept: standalone backend with full FE/BE protocol (Aidan Van Dyk <aidan@highrise.ca>) |
Ответы |
Re: Proof of concept: standalone backend with full FE/BE
protocol
Re: Proof of concept: standalone backend with full FE/BE protocol |
Список | pgsql-hackers |
Aidan Van Dyk <aidan@highrise.ca> writes: > So, in the spirit of not painting ourselves into a tiny corner here on > the whole "single backend" and "embedded database" problem with pg > options, can we generalize this a bit? > Any way we could make psql connect to a "given fd", as an option? In > theory, that could be something opened by some out-side-of-postgresql > tunnel with 3rd party auth in the same app that uses libpq directly, > or it could be a fd prepared by something that specifically launched > a single-backend postgres, like in the case of pg_upgrade, pg_uprade > itself, and passed to psql, etc, which would be passed in as options. 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. regards, tom lane
В списке pgsql-hackers по дате отправления: