psql patch: new host/port without leaving session

Patch applied. Thanks.

---------------------------------------------------------------------------

David Fetter wrote:

Folks,

Please find enclosed a patch that lets you use \c to connect
(optionally) to a new host and port without exiting psql. This
eliminates, IMHO, a surprise in that you can now connect to PostgreSQL
on a differnt machine from the one where you started your session.
This should help people who use psql as an administrative tool.

Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 415 235 3778

Remember to vote!

[ Attachment, skipping... ]

---------------------------(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

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Hi,

I've written do_connect() and \c handling part from scratch in the
attached patch. Here are some features introduced:

- \c syntax is extended. (See comment lines just above \c stuff.)
- do_connect() AI (like used for prompting password or informing
client about connect attempt's result.) improved.
- Some code clean up.

If you'd agree with the style, I'll add patch for the documentation and
PO files too.

Regards.

P.S. Patch passed regressions tests on CVS tip.

On Sun, 2006-03-12 at 19:59 +0200, Volkan YAZICI wrote:

I've written do_connect() and \c handling part from scratch in the
attached patch.

Attached is a revised version of this patch. I rewrote most of the code,
because the existing stuff was in pretty bad style IMHO. I haven't
updated the documentation yet, but I'll do that if no one objects to
this version of the patch.

One question about behavior: in the attached patch, omitting an argument
to \connect or specifying "-" are treated equivalently -- the value for
that parameter from the previous connection is used, otherwise NULL (for
the libpq default). Is this what people want? (One possible complaint is
that once you specify a parameter, you can't get back to the libpq
default without specifying it explicitly.)

-Neil

Neil Conway <neilc@samurai.com> writes:

One question about behavior: in the attached patch, omitting an argument
to \connect or specifying "-" are treated equivalently -- the value for
that parameter from the previous connection is used, otherwise NULL (for
the libpq default). Is this what people want?

Yes, that's the behavior I'd expect. The traditional \c behavior for
the two longstanding options (dbname and username) was exactly that,
no?

regards, tom lane

On Apr 01 07:07, Neil Conway wrote:

One question about behavior: in the attached patch, omitting an argument
to \connect or specifying "-" are treated equivalently -- the value for
that parameter from the previous connection is used, otherwise NULL (for
the libpq default). Is this what people want? (One possible complaint is
that once you specify a parameter, you can't get back to the libpq
default without specifying it explicitly.)

Won't it be better if we distinguish between "default" and "current"
value of a parameter with '-' (for the "current") and '+' (for the
"default") characters? For example:

\c + - hst
Connect to "default" database with "current" user on host hst.
(Omitted values can be treated as "current".)

\c + + hst -
Connect to "default" database with "default" user on host hst on
"current" port.

So we'll still have chance to get back to the libpq defaults.

Regards.

Volkan YAZICI <yazicivo@ttnet.net.tr> writes:

On Apr 01 07:07, Neil Conway wrote:

One question about behavior: in the attached patch, omitting an argument
to \connect or specifying "-" are treated equivalently -- the value for
that parameter from the previous connection is used, otherwise NULL (for
the libpq default). Is this what people want? (One possible complaint is
that once you specify a parameter, you can't get back to the libpq
default without specifying it explicitly.)

Won't it be better if we distinguish between "default" and "current"
value of a parameter with '-' (for the "current") and '+' (for the
"default") characters? For example:

That seems like a frammish without sufficient use-case. You can always
quit and restart psql to get back to the defaults.

regards, tom lane

On Apr 02 12:37, Tom Lane wrote:

Volkan YAZICI <yazicivo@ttnet.net.tr> writes:

Won't it be better if we distinguish between "default" and "current"
value of a parameter with '-' (for the "current") and '+' (for the
"default") characters? For example:

That seems like a frammish without sufficient use-case. You can always
quit and restart psql to get back to the defaults.

You can always quit and restart psql with new connection parameters.
In this situation, we shouldn't bother with \c too. Don't they share
the same use-case? (If there's any.)

Regards.

On Sun, 2006-04-02 at 12:37 -0400, Tom Lane wrote:

That seems like a frammish without sufficient use-case. You can always
quit and restart psql to get back to the defaults.

Patch applied to HEAD.

If folks want to argue for the ability to instruct psql to use the libpq
default for a parameter, I'm not fundamentally opposed, but that change
can be made subsequently.

-Neil

Neil Conway wrote:

On Sun, 2006-04-02 at 12:37 -0400, Tom Lane wrote:

That seems like a frammish without sufficient use-case. You can always
quit and restart psql to get back to the defaults.

Patch applied to HEAD.

If folks want to argue for the ability to instruct psql to use the libpq
default for a parameter, I'm not fundamentally opposed, but that change
can be made subsequently.

I think what is applied is enough. That +/- syntax was too confusing to
be useful.

--
Bruce Momjian http://candle.pha.pa.us

+ If your life is a hard drive, Christ can be your backup. +