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

From Robert Haas
Subject Re: Proof of concept: standalone backend with full FE/BE protocol
Date
Msg-id CA+TgmoY0xgra_Js4xcCXQqZJhp3b2wzx3qeDnECVkEuR+ED-_A@mail.gmail.com
Whole thread Raw
In response to Re: Proof of concept: standalone backend with full FE/BE protocol  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Wed, Nov 20, 2013 at 3:32 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On 11/20/13, 3:24 PM, Robert Haas wrote:
>> The point is that client applications should expose whether or not to
>> set this function as a command-line switch separate from whatever they
>> accept in terms of connection strings.  So pg_dump should have a flag
>> called --standalone-server or something like, and it should all
>> PQenableStartServer() only when that flag is used.
>
> The argument elsewhere in this thread was that the reason for putting
> this in the connection options was so that you do *not* have to patch up
> every client to be able to use this functionality.  If you have to add
> separate options everywhere, then you might as well just have a separate
> libpq function to initiate the session.

Well, that's fair enough.  I don't care much what the syntax is for
invoking the postmaster this way, as long as it's reasonably
convenient.  I just want there to be one.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: David Johnston
Date:
Subject: Re: WITH ORDINALITY versus column definition lists
Next
From: Tom Lane
Date:
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol