Re: Proof of concept: standalone backend with full FE/BE protocol - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Proof of concept: standalone backend with full FE/BE protocol
Date
Msg-id CA+U5nMKAW3ENRb4rqsgU1zWoOrMhTuogT3Rjm7wPn+zbUH0pNA@mail.gmail.com
Whole thread Raw
In response to Re: Proof of concept: standalone backend with full FE/BE protocol  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: Proof of concept: standalone backend with full FE/BE protocol
List pgsql-hackers
On 12 November 2012 21:26, Merlin Moncure <mmoncure@gmail.com> wrote:

> I couldn't disagree more.  The patch is small, logical, and fixes an
> awful problem, namely that --single mode is basically unusable.  As to
> your wider point (namely, that you can't connect to it, therefore it's
> bad), it has got to be refuted by numerous competing solutions in the
> market such as http://www.firebirdsql.org/manual/fbmetasecur-embedded.html,
> and many others.

Small is not an argument in favour, just a statement of ease, like
jumping off a cliff. i.e. lemmings.

> While it's not as common as it used to be, now and then a piece of
> software needs to distribute an application as part of a boxed
> product.  Postgres is horrible at this and doesn't have to be; imagine
> how much easier the lives of poker tracker would be (for *some* of its
> users) with an integrated standalone mode: google 'poker tracker
> postgresql' and take a good long look at problems people face in this
> scenario.

I get the installability thang, very very much, I just don't see the
single process thing as the only solution. At very least an open
minded analysis of the actual problem and ways of solving it is called
for, not just reach for a close to hand solution.

I don't ever want to hear someone reject a patch cos it would mess up
poker tracker. The point is it complicates the code, introduces
restrictions into what is possible and is just more inertia onto
development.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Further pg_upgrade analysis for many tables
Next
From: Jeff Janes
Date:
Subject: Re: Further pg_upgrade analysis for many tables