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

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, hlinnaka(at)iki(dot)fi, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol
Date: 2012-11-12 21:41:29
Message-ID: CA+U5nMKAW3ENRb4rqsgU1zWoOrMhTuogT3Rjm7wPn+zbUH0pNA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12 November 2012 21:26, Merlin Moncure <mmoncure(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2012-11-12 21:54:28 Re: Further pg_upgrade analysis for many tables
Previous Message Bruce Momjian 2012-11-12 21:32:35 Re: Further pg_upgrade analysis for many tables