Skip site navigation (1) Skip section navigation (2)

Re: Concurrent psql patch

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "David Fetter" <david(at)fetter(dot)org>, "Jim Nasby" <decibel(at)decibel(dot)org>, "pgsql-patches" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Concurrent psql patch
Date: 2007-05-13 23:05:18
Message-ID: 87d51472a9.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> "David Fetter" <david(at)fetter(dot)org> writes:
>>> What's the reasoning behind \c&?  Does it "send things into the
>>> background" the way & does in the shell?
>
>> Sort of. It sends the *subsequent* command to the background...
>
> That sounds just bizarre.  Existing backslash commands that do something
> to a SQL command are typed *after* the command they affect (\g for
> instance).  I don't think you should randomly change that.

So would you prefer \g& as Jim Nasby suggested? I hadn't even considered that
previously since I'm not accustomed to using \g but it does seem kind of
pretty. I normally use ; but I suppose there's nothing wrong with just
declaring that asynchronous commands must be issued using \g& rather than use
the semicolon to fire them off.

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com


In response to

Responses

pgsql-hackers by date

Next:From: CK TanDate: 2007-05-13 23:41:29
Subject: Re: Seq scans roadmap
Previous:From: Tom LaneDate: 2007-05-13 22:44:02
Subject: Re: Concurrent psql patch

pgsql-patches by date

Next:From: Tom LaneDate: 2007-05-13 23:42:36
Subject: Re: Have vacuum emit a warning when it runs out of maintenance_work_mem
Previous:From: Andrew DunstanDate: 2007-05-13 23:04:44
Subject: Re: [PATCHES] OS/X startup scripts

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group