SEO

"Jim Nasby" <decibel@decibel.org> writes:

> I don't see how we could make the names shorter without moving away from a
> backslash command (which I'm guessing would be painful).
>
> Assuming we're stuck with a backslash command \cs[witch] and \cn
> [owait] seem to be about as good as we could get.

I don't have \cs or \cn set up as abbreviations.

I was originally thinking \c1, \c2, ... for \cswitch and \c& for \cnowait. I'm
not sure if going for cryptic short commands is better or worse here.

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


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On Sun, May 13, 2007 at 02:39:45PM +0100, Gregory Stark wrote:
> "Jim Nasby" <decibel@decibel.org> writes:
>
> > I don't see how we could make the names shorter without moving
> > away from a backslash command (which I'm guessing would be
> > painful).
> >
> > Assuming we're stuck with a backslash command \cs[witch] and \cn
> > [owait] seem to be about as good as we could get.
>
> I don't have \cs or \cn set up as abbreviations.
>
> I was originally thinking \c1, \c2, ... for \cswitch and \c& for
> \cnowait. I'm not sure if going for cryptic short commands is better
> or worse here.

+1 for \c1, \c2, etc.

What's the reasoning behind \c&? Does it "send things into the
background" the way & does in the shell?

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter

Remember to vote!
Consider donating to PostgreSQL: http://www.postgresql.org/about/donate

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Sun, May 13, 2007 at 02:39:45PM +0100, Gregory Stark wrote:
> "Jim Nasby" <decibel@decibel.org> writes:
>
> > I don't see how we could make the names shorter without moving away from a
> > backslash command (which I'm guessing would be painful).
> >
> > Assuming we're stuck with a backslash command \cs[witch] and \cn
> > [owait] seem to be about as good as we could get.
>
> I don't have \cs or \cn set up as abbreviations.
>
> I was originally thinking \c1, \c2, ... for \cswitch and \c& for \cnowait. I'm
> not sure if going for cryptic short commands is better or worse here.

Would \c# limit us to 9 concurrent connections? Might want

\cs[witch] [session]

which would switch to the specified session. If none specified, it would
switch back to whatever session was previously active.

\c& sounds fine (as do \c1...\c9). \g& would probably be helpful as well
(send query buffer to server in nowait mode).
--
Jim Nasby decibel@decibel.org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

"Jim C. Nasby" <decibel@decibel.org> writes:

> On Sun, May 13, 2007 at 02:39:45PM +0100, Gregory Stark wrote:
>>
>> I was originally thinking \c1, \c2, ... for \cswitch and \c& for \cnowait. I'm
>> not sure if going for cryptic short commands is better or worse here.
>
> \c& sounds fine (as do \c1...\c9). \g& would probably be helpful as well
> (send query buffer to server in nowait mode).

Er, I just realized I typed the wrong thing there. It can't be \c& since I do
assign a meaning to that "make a new connection to the same place as this
one".

I meant \&

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


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Gregory Stark <stark@enterprisedb.com> writes:
> "David Fetter" <david@fetter.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.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Gregory Stark <stark@enterprisedb.com> writes:
>> "David Fetter" <david@fetter.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


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Gregory Stark <stark@enterprisedb.com> writes:
> 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.

It makes sense to me... but what is the state of the session afterward?
Should this be combined with switching to another connection?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Gregory Stark <stark@enterprisedb.com> writes:
>> 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.
>
> It makes sense to me... but what is the state of the session afterward?
> Should this be combined with switching to another connection?

It's an interesting idea since you'll inevitably have to switch connections.
If you issue a second query it'll forces the session to wait for the results.
(It doesn't seem like there's any point in keeping a queue of pending queries
per session.)

However we do still need a command to switch back anyways so there doesn't
seem to be any advantage in combining the two.

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


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

"Jim C. Nasby" <decibel@decibel.org> writes:

> Would \c# limit us to 9 concurrent connections? Might want
>
> \cs[witch] [session]

Hm, we kind of have a choice with \c#. Either we treat it as part of the
command in which case the way to connect to an integer-named database is to
include a space. We could even have it magically connect to a database if the
connection isn't already active.

But these kinds of inconsistent behaviours can be traps for users. It means
"\c1" and "\c 1" do different things even though "\cpostgres" and \c postgres"
do the same thing. And it means "\c1" might connect to a database named "1"
today but switch sessions tomorrow.

Or we treat it as the first argument in which case even "\c 9" switches to
session 9. I would prefer to do that but I fear there may be people with
databases named "9".

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


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Gregory Stark <stark@enterprisedb.com> writes:
> But these kinds of inconsistent behaviours can be traps for users. It means
> "\c1" and "\c 1" do different things even though "\cpostgres" and \c postgres"
> do the same thing. And it means "\c1" might connect to a database named "1"
> today but switch sessions tomorrow.

The real problem here is trying to overload an existing command name
with too many different meanings. You need to pick some other name
besides \c.

If you were willing to think of it as "switch session" instead of "connect",
then \S is available ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org