Re: Proof of concept: standalone backend with full FE/BE protocol

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Aidan Van Dyk <aidan@highrise.ca>
Cc: Daniel Farina <daniel@heroku.com>, Peter Eisentraut <peter_e@gmx.net>, Josh Berkus <josh@agliodbs.com>, pgsql-hackers@postgresql.org
Date: 2012-09-06T02:14:36Z
Lists: 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


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Remove now redundant pgpipe code.