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

From Bruce Momjian
Subject Re: Proof of concept: standalone backend with full FE/BE protocol
Date
Msg-id 20131210034241.GG2119@momjian.us
Whole thread Raw
In response to Re: Proof of concept: standalone backend with full FE/BE protocol  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Fri, Dec  6, 2013 at 04:04:36PM +0100, Andres Freund wrote:
> On 2013-12-05 23:01:28 +0200, Heikki Linnakangas wrote:
> > On 12/05/2013 10:37 PM, Robert Haas wrote:
> > >On Thu, Dec 5, 2013 at 3:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > >>It might be unpleasant to use in some cases, though.
> > >
> > >Why would there be more than a few cases in the first place?  Who is
> > >going to use this beyond psql, pg_dump(all), and pg_upgrade, and why?
> > 
> > Well, you might want to use pgAdmin, or your other favorite admin tool. I'm
> > not sure how well it would work, and I think it's OK if we say "sorry, can't
> > do that", but it's not a crazy thing to want.
> 
> Pgadmin wouldn't work, it uses multiple connections for anything but the
> most trivial tasks. You can't even send a manual sql query using only
> one connection.
> I think that's true for most of the non-trivial tools.

FYI, pg_upgrade in parallel mode needs multiple database connections
too.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core
Next
From: Michael Paquier
Date:
Subject: Re: [patch] Adding EXTRA_REGRESS_OPTS to all pg_regress invocations