"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.
In response to
pgsql-hackers by date
|Next:||From: CK Tan||Date: 2007-05-13 23:41:29|
|Subject: Re: Seq scans roadmap|
|Previous:||From: Tom Lane||Date: 2007-05-13 22:44:02|
|Subject: Re: Concurrent psql patch |
pgsql-patches by date
|Next:||From: Tom Lane||Date: 2007-05-13 23:42:36|
|Subject: Re: Have vacuum emit a warning when it runs out of maintenance_work_mem |
|Previous:||From: Andrew Dunstan||Date: 2007-05-13 23:04:44|
|Subject: Re: [PATCHES] OS/X startup scripts|