Patch: psql \whoami option

-hackers,

In the spirit of small, but hopefully useful interface improvement
patches, enclosed for your review is a patch for providing psql with a
\whoami command (maybe a better name is \conninfo or similar). Its
purpose is to print information about the current connection, by
default in a human-readable format. There is also an optional format
parameter which currently accepts 'dsn' as an option to output the
current connection information as a DSN.

Example output:

$psql -d postgres -p 8555
psql (8.5devel)
You are now connected to database "postgres".

[Tue Jan 26 17:17:31 CST 2010]
machack:postgres:8555=# \whoami
Connected to database: "postgres", user: "machack", port: "8555"
via local domain socket

[Tue Jan 26 17:17:34 CST 2010]
machack:postgres:8555=# \c - - localhost 8555
psql (8.5devel)
You are now connected to database "postgres" on host "localhost".

[Tue Jan 26 17:17:42 CST 2010]
machack:postgres:8555=# \whoami
Connected to database: "postgres", user: "machack", host:
"localhost", port: "8555"

[Tue Jan 26 17:17:46 CST 2010]
machack:postgres:8555=# \whoami dsn
dbname=postgres;user=machack;host=localhost;port=8555

[Tue Jan 26 17:19:02 CST 2010]
machack:postgres:8555=# \q

Regards,

David
--
David Christensen
End Point Corporation
david(at)endpoint(dot)com

diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-
ref.sgml
index 3ce5996..b58b24d 100644
*** a/doc/src/sgml/ref/psql-ref.sgml
--- b/doc/src/sgml/ref/psql-ref.sgml
*************** lo_import 152801
*** 2149,2154 ****
--- 2149,2167 ----

<varlistentry>
+ <term><literal>\whoami</literal> [ <replaceable
class="parameter">default</replaceable> | <replaceable
class="parameter">dsn</replaceable> ] </term>
+ <listitem>
+ <para>
+ Outputs connection information about the current database
+ connection. When passed parameter <literal>dsn</literal>,
+ outputs as a DSN. If parameter is unspecified or
+ unrecognized, outputs in a human-readable format.
+ </para>
+ </listitem>
+ </varlistentry>
+
+
+ <varlistentry>
<term><literal>\x</literal></term>
<listitem>
<para>
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 5188b18..21b2468 100644
*** a/src/bin/psql/command.c
--- b/src/bin/psql/command.c
*************** exec_command(const char *cmd,
*** 1106,1111 ****
--- 1106,1156 ----
free(fname);
}

+ /* \whoami -- display information about the current connection */
+ else if (strcmp(cmd, "whoami") == 0)
+ {
+ char *format = psql_scan_slash_option(scan_state,
+ OT_NORMAL, NULL, true);
+ char *host = PQhost(pset.db);
+
+ if (format && !pg_strcasecmp(format, "dsn")) {
+ if (host) {
+ printf("dbname=%s;user=%s;host=%s;port=%s\n",
+ PQdb(pset.db),
+ PQuser(pset.db),
+ host,
+ PQport(pset.db)
+ );
+ }
+ else {
+ printf("dbname=%s;user=%s;port=%s\n",
+ PQdb(pset.db),
+ PQuser(pset.db),
+ PQport(pset.db)
+ );
+ }
+ }
+ else {
+ /* default case */
+ if (host) {
+ printf("Connected to database: \"%s\", user: \"%s\", host: \"%s
\", port: \"%s\"\n",
+ PQdb(pset.db),
+ PQuser(pset.db),
+ host,
+ PQport(pset.db)
+ );
+ }
+ else {
+ printf("Connected to database: \"%s\", user: \"%s\", port: \"%s
\" via local domain socket\n",
+ PQdb(pset.db),
+ PQuser(pset.db),
+ PQport(pset.db)
+ );
+ }
+ }
+ free(format);
+ }
+
/* \x -- toggle expanded table representation */
else if (strcmp(cmd, "x") == 0)
{
diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c
index 6037351..802b76d 100644
*** a/src/bin/psql/help.c
--- b/src/bin/psql/help.c
*************** slashUsage(unsigned short int pager)
*** 249,254 ****
--- 249,256 ----
PQdb(pset.db));
fprintf(output, _(" \\encoding [ENCODING] show or set client
encoding\n"));
fprintf(output, _(" \\password [USERNAME] securely change the
password for a user\n"));
+ fprintf(output, _(" \\whoami [FORMAT] display information
about current connection\n"
+ " (FORMAT := {default|
dsn})\n"));
fprintf(output, "\n");

fprintf(output, _("Operating System\n"));
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
index cb2ae9a..952d2bc 100644
*** a/src/bin/psql/tab-complete.c
--- b/src/bin/psql/tab-complete.c
*************** psql_completion(char *text, int start, i
*** 635,641 ****
"\\lo_import", "\\lo_export", "\\lo_list", "\\lo_unlink",
"\\o", "\\p", "\\password", "\\prompt", "\\pset", "\\q", "\
\qecho", "\\r",
"\\set", "\\t", "\\T",
! "\\timing", "\\unset", "\\x", "\\w", "\\z", "\\!", NULL
};

(void) end; /* not used */
--- 635,641 ----
"\\lo_import", "\\lo_export", "\\lo_list", "\\lo_unlink",
"\\o", "\\p", "\\password", "\\prompt", "\\pset", "\\q", "\
\qecho", "\\r",
"\\set", "\\t", "\\T",
! "\\timing", "\\unset", "\\x", "\\w", "\\whoami", "\\z", "\\!", NULL
};

(void) end; /* not used */

On 1/26/10 3:24 PM, David Christensen wrote:
> -hackers,
>
> In the spirit of small, but hopefully useful interface improvement
> patches, enclosed for your review is a patch for providing psql with a
> \whoami command (maybe a better name is \conninfo or similar). Its
> purpose is to print information about the current connection, by default
> in a human-readable format. There is also an optional format parameter
> which currently accepts 'dsn' as an option to output the current
> connection information as a DSN.

oooh, I could really use this. +1 to put it in 9.1-first CF.

however, \conninfo is probably the better name. And what about a
postgresql function version for non-psql connections?

--Josh Berkus

2010/1/27 Josh Berkus <josh(at)agliodbs(dot)com>:
> On 1/26/10 3:24 PM, David Christensen wrote:
>> -hackers,
>>
>> In the spirit of small, but hopefully useful interface improvement
>> patches, enclosed for your review is a patch for providing psql with a
>> \whoami command (maybe a better name is \conninfo or similar).  Its
>> purpose is to print information about the current connection, by default
>> in a human-readable format.  There is also an optional format parameter
>> which currently accepts 'dsn' as an option to output the current
>> connection information as a DSN.

On a first note, it seems like the check for the parameter "dsn" isn't
"complete". Without testing it, it looks like it would be possible to
run "\whoami foobar", which should give an error.

> oooh, I could really use this.  +1 to put it in 9.1-first CF.
>
> however, \conninfo is probably the better name.  And what about a

+1 on that name.

> postgresql function version for non-psql connections?

How could that function possibly know what the connection looks like
from the client side? Think NAT, think proxies, think connection
poolers.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

How about using the psql prompt to convey this information? IIRC the
psql prompt can be configured to show the hostname, server, port and
other fields. Wouldn't this be enough? or am I missing something?

- Martin -

On 27 Jan 2010, at 13:01, Magnus Hagander wrote:

> 2010/1/27 Josh Berkus <josh(at)agliodbs(dot)com>:
>> On 1/26/10 3:24 PM, David Christensen wrote:
>>> -hackers,
>>>
>>> In the spirit of small, but hopefully useful interface improvement
>>> patches, enclosed for your review is a patch for providing psql
>>> with a
>>> \whoami command (maybe a better name is \conninfo or similar). Its
>>> purpose is to print information about the current connection, by
>>> default
>>> in a human-readable format. There is also an optional format
>>> parameter
>>> which currently accepts 'dsn' as an option to output the current
>>> connection information as a DSN.
>
> On a first note, it seems like the check for the parameter "dsn" isn't
> "complete". Without testing it, it looks like it would be possible to
> run "\whoami foobar", which should give an error.
>
>
>> oooh, I could really use this. +1 to put it in 9.1-first CF.
>>
>> however, \conninfo is probably the better name. And what about a
>
> +1 on that name.
>
>> postgresql function version for non-psql connections?
>
> How could that function possibly know what the connection looks like
> from the client side? Think NAT, think proxies, think connection
> poolers.
>
> --
> Magnus Hagander
> Me: http://www.hagander.net/
> Work: http://www.redpill-linpro.com/
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

I think the idea is that if you do that, it'll be there all the time,
potentially "crowding the space".

//Magnus

2010/1/27 Martin Atukunda <matlads(at)gmail(dot)com>:
> How about using the psql prompt to convey this information? IIRC the psql prompt can be configured to show the hostname, server, port and other fields. Wouldn't this be enough? or am I missing something?
>
> - Martin -
>
> On 27 Jan 2010, at 13:01, Magnus Hagander wrote:
>
>> 2010/1/27 Josh Berkus <josh(at)agliodbs(dot)com>:
>>>
>>> On 1/26/10 3:24 PM, David Christensen wrote:
>>>>
>>>> -hackers,
>>>>
>>>> In the spirit of small, but hopefully useful interface improvement
>>>> patches, enclosed for your review is a patch for providing psql with a
>>>> \whoami command (maybe a better name is \conninfo or similar).  Its
>>>> purpose is to print information about the current connection, by default
>>>> in a human-readable format.  There is also an optional format parameter
>>>> which currently accepts 'dsn' as an option to output the current
>>>> connection information as a DSN.
>>
>> On a first note, it seems like the check for the parameter "dsn" isn't
>> "complete". Without testing it, it looks like it would be possible to
>> run "\whoami foobar", which should give an error.
>>
>>
>>> oooh, I could really use this.  +1 to put it in 9.1-first CF.
>>>
>>> however, \conninfo is probably the better name.  And what about a
>>
>> +1 on that name.
>>
>>> postgresql function version for non-psql connections?
>>
>> How could that function possibly know what the connection looks like
>> from the client side? Think NAT, think proxies, think connection
>> poolers.
>>
>> --
>> Magnus Hagander
>> Me: http://www.hagander.net/
>> Work: http://www.redpill-linpro.com/
>>
>> --
>> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-hackers
>
>

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

2010/1/27 Josh Berkus <josh(at)agliodbs(dot)com>

>
> however, \conninfo is probably the better name.
>

+1

Something along the lines of: "Connected to localhost port 5432 as user
thomb"?

Thom

2010/1/27 Thom Brown <thombrown(at)gmail(dot)com>

> 2010/1/27 Josh Berkus <josh(at)agliodbs(dot)com>
>
>>
>> however, \conninfo is probably the better name.
>>
>
> +1
>
> Something along the lines of: "Connected to localhost port 5432 as user
> thomb"?
>
> Thom
>
> Er... ignore that. Just saw the other examples which are better ;)

On Jan 27, 2010, at 4:01 AM, Magnus Hagander wrote:

> 2010/1/27 Josh Berkus <josh(at)agliodbs(dot)com>:
>> On 1/26/10 3:24 PM, David Christensen wrote:
>>> -hackers,
>>>
>>> In the spirit of small, but hopefully useful interface improvement
>>> patches, enclosed for your review is a patch for providing psql
>>> with a
>>> \whoami command (maybe a better name is \conninfo or similar). Its
>>> purpose is to print information about the current connection, by
>>> default
>>> in a human-readable format. There is also an optional format
>>> parameter
>>> which currently accepts 'dsn' as an option to output the current
>>> connection information as a DSN.
>
> On a first note, it seems like the check for the parameter "dsn" isn't
> "complete". Without testing it, it looks like it would be possible to
> run "\whoami foobar", which should give an error.

Yeah, I debated that; right now, it just ignores any output it doesn't
know about and spits out the human-readable format.

>> oooh, I could really use this. +1 to put it in 9.1-first CF.
>>
>> however, \conninfo is probably the better name. And what about a
>
> +1 on that name.

That makes at least three, including me. :-)

>> postgresql function version for non-psql connections?
>
> How could that function possibly know what the connection looks like
> from the client side? Think NAT, think proxies, think connection
> poolers.

Yes, this doesn't seem to be a feasible thing to detect in all (many?)
cases.

Regards,

David
--
David Christensen
End Point Corporation
david(at)endpoint(dot)com

On Jan 27, 2010, at 5:23 AM, Martin Atukunda wrote:

> How about using the psql prompt to convey this information? IIRC the
> psql prompt can be configured to show the hostname, server, port and
> other fields. Wouldn't this be enough? or am I missing something?

Prompt customization is certainly something that could be done (and I
use in my .psqlrc), but consider someone unaware of the psql prompt
customization or people who are not using their own setup/account,
etc. This is a command that could be useful for anyone; as experts,
we tend to miss some of the holes in the current interfaces.

Regards,

David
--
David Christensen
End Point Corporation
david(at)endpoint(dot)com

2010/1/27 David Christensen <david(at)endpoint(dot)com>:
>
> On Jan 27, 2010, at 4:01 AM, Magnus Hagander wrote:
>
>> 2010/1/27 Josh Berkus <josh(at)agliodbs(dot)com>:
>>>
>>> On 1/26/10 3:24 PM, David Christensen wrote:
>>>>
>>>> -hackers,
>>>>
>>>> In the spirit of small, but hopefully useful interface improvement
>>>> patches, enclosed for your review is a patch for providing psql with a
>>>> \whoami command (maybe a better name is \conninfo or similar).  Its
>>>> purpose is to print information about the current connection, by default
>>>> in a human-readable format.  There is also an optional format parameter
>>>> which currently accepts 'dsn' as an option to output the current
>>>> connection information as a DSN.
>>
>> On a first note, it seems like the check for the parameter "dsn" isn't
>> "complete". Without testing it, it looks like it would be possible to
>> run "\whoami foobar", which should give an error.
>
> Yeah, I debated that; right now, it just ignores any output it doesn't know about and spits out the human-readable format.

yeah, that's not very forwards-compatible. Someone uses it in the
wrong way, and suddenly their stuff gets broken if we choose to modify
it in the future. If we say we're only going ot accept two options,
let's enforce that and show an error/help message if the user typos.

Guessing is not what we do :-) We leave that to other databases...

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On Jan 27, 2010, at 8:08 AM, Magnus Hagander wrote:

> 2010/1/27 David Christensen <david(at)endpoint(dot)com>:
>>
>> On Jan 27, 2010, at 4:01 AM, Magnus Hagander wrote:
>>
>>> 2010/1/27 Josh Berkus <josh(at)agliodbs(dot)com>:
>>>>
>>>> On 1/26/10 3:24 PM, David Christensen wrote:
>>>>>
>>>>> -hackers,
>>>>>
>>>>> In the spirit of small, but hopefully useful interface improvement
>>>>> patches, enclosed for your review is a patch for providing psql
>>>>> with a
>>>>> \whoami command (maybe a better name is \conninfo or similar).
>>>>> Its
>>>>> purpose is to print information about the current connection, by
>>>>> default
>>>>> in a human-readable format. There is also an optional format
>>>>> parameter
>>>>> which currently accepts 'dsn' as an option to output the current
>>>>> connection information as a DSN.
>>>
>>> On a first note, it seems like the check for the parameter "dsn"
>>> isn't
>>> "complete". Without testing it, it looks like it would be possible
>>> to
>>> run "\whoami foobar", which should give an error.
>>
>> Yeah, I debated that; right now, it just ignores any output it
>> doesn't know about and spits out the human-readable format.
>
> yeah, that's not very forwards-compatible. Someone uses it in the
> wrong way, and suddenly their stuff gets broken if we choose to modify
> it in the future. If we say we're only going ot accept two options,
> let's enforce that and show an error/help message if the user typos.

That's a good point about forward-compatibility. In that case, I'm
not sure if "default" is the best name for the human-readable format,
but I didn't like "human-readable" ;-). I assume that should have an
explicit spelling, and not just be the format that we get if we don't
otherwise specify. Ideas, anyone?

Regards,

David
--
David Christensen
End Point Corporation
david(at)endpoint(dot)com

David Christensen <david(at)endpoint(dot)com> writes:
> That's a good point about forward-compatibility. In that case, I'm
> not sure if "default" is the best name for the human-readable format,
> but I didn't like "human-readable" ;-). I assume that should have an
> explicit spelling, and not just be the format that we get if we don't
> otherwise specify. Ideas, anyone?

I think this patch has near zero usecase already, and more than one
output format is *definitely* a waste of time. Forget the argument and
just print the "human readable" format.

regards, tom lane

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> 2010/1/27 Martin Atukunda <matlads(at)gmail(dot)com>:
>> How about using the psql prompt to convey this information?

> I think the idea is that if you do that, it'll be there all the time,
> potentially "crowding the space".

I had the same reaction as Martin. If you want this info all the time,
setting the prompt is the way to go. If you only want it occasionally,
you're probably more likely to remember other ways of getting the info
first (session_user, pg_stat_activity, etc etc). There may be some
use-case in between where another backslash command would be helpful,
but it seems a tad marginal to me. I don't object as long as it's not
overdesigned, but let's keep the bells and whistles to a minimum.

regards, tom lane

I have added this patch to the next commit-fest. Thanks:

https://commitfest.postgresql.org/action/commitfest_view?id=6

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

David Christensen wrote:
> -hackers,
>
> In the spirit of small, but hopefully useful interface improvement
> patches, enclosed for your review is a patch for providing psql with a
> \whoami command (maybe a better name is \conninfo or similar). Its
> purpose is to print information about the current connection, by
> default in a human-readable format. There is also an optional format
> parameter which currently accepts 'dsn' as an option to output the
> current connection information as a DSN.
>
> Example output:
>
> $psql -d postgres -p 8555
> psql (8.5devel)
> You are now connected to database "postgres".
>
> [Tue Jan 26 17:17:31 CST 2010]
> machack:postgres:8555=# \whoami
> Connected to database: "postgres", user: "machack", port: "8555"
> via local domain socket
>
> [Tue Jan 26 17:17:34 CST 2010]
> machack:postgres:8555=# \c - - localhost 8555
> psql (8.5devel)
> You are now connected to database "postgres" on host "localhost".
>
> [Tue Jan 26 17:17:42 CST 2010]
> machack:postgres:8555=# \whoami
> Connected to database: "postgres", user: "machack", host:
> "localhost", port: "8555"
>
> [Tue Jan 26 17:17:46 CST 2010]
> machack:postgres:8555=# \whoami dsn
> dbname=postgres;user=machack;host=localhost;port=8555
>
> [Tue Jan 26 17:19:02 CST 2010]
> machack:postgres:8555=# \q
>
> Regards,
>
> David
> --
> David Christensen
> End Point Corporation
> david(at)endpoint(dot)com
>
>
>
> diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-
> ref.sgml
> index 3ce5996..b58b24d 100644
> *** a/doc/src/sgml/ref/psql-ref.sgml
> --- b/doc/src/sgml/ref/psql-ref.sgml
> *************** lo_import 152801
> *** 2149,2154 ****
> --- 2149,2167 ----
>
>
> <varlistentry>
> + <term><literal>\whoami</literal> [ <replaceable
> class="parameter">default</replaceable> | <replaceable
> class="parameter">dsn</replaceable> ] </term>
> + <listitem>
> + <para>
> + Outputs connection information about the current database
> + connection. When passed parameter <literal>dsn</literal>,
> + outputs as a DSN. If parameter is unspecified or
> + unrecognized, outputs in a human-readable format.
> + </para>
> + </listitem>
> + </varlistentry>
> +
> +
> + <varlistentry>
> <term><literal>\x</literal></term>
> <listitem>
> <para>
> diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
> index 5188b18..21b2468 100644
> *** a/src/bin/psql/command.c
> --- b/src/bin/psql/command.c
> *************** exec_command(const char *cmd,
> *** 1106,1111 ****
> --- 1106,1156 ----
> free(fname);
> }
>
> + /* \whoami -- display information about the current connection */
> + else if (strcmp(cmd, "whoami") == 0)
> + {
> + char *format = psql_scan_slash_option(scan_state,
> + OT_NORMAL, NULL, true);
> + char *host = PQhost(pset.db);
> +
> + if (format && !pg_strcasecmp(format, "dsn")) {
> + if (host) {
> + printf("dbname=%s;user=%s;host=%s;port=%s\n",
> + PQdb(pset.db),
> + PQuser(pset.db),
> + host,
> + PQport(pset.db)
> + );
> + }
> + else {
> + printf("dbname=%s;user=%s;port=%s\n",
> + PQdb(pset.db),
> + PQuser(pset.db),
> + PQport(pset.db)
> + );
> + }
> + }
> + else {
> + /* default case */
> + if (host) {
> + printf("Connected to database: \"%s\", user: \"%s\", host: \"%s
> \", port: \"%s\"\n",
> + PQdb(pset.db),
> + PQuser(pset.db),
> + host,
> + PQport(pset.db)
> + );
> + }
> + else {
> + printf("Connected to database: \"%s\", user: \"%s\", port: \"%s
> \" via local domain socket\n",
> + PQdb(pset.db),
> + PQuser(pset.db),
> + PQport(pset.db)
> + );
> + }
> + }
> + free(format);
> + }
> +
> /* \x -- toggle expanded table representation */
> else if (strcmp(cmd, "x") == 0)
> {
> diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c
> index 6037351..802b76d 100644
> *** a/src/bin/psql/help.c
> --- b/src/bin/psql/help.c
> *************** slashUsage(unsigned short int pager)
> *** 249,254 ****
> --- 249,256 ----
> PQdb(pset.db));
> fprintf(output, _(" \\encoding [ENCODING] show or set client
> encoding\n"));
> fprintf(output, _(" \\password [USERNAME] securely change the
> password for a user\n"));
> + fprintf(output, _(" \\whoami [FORMAT] display information
> about current connection\n"
> + " (FORMAT := {default|
> dsn})\n"));
> fprintf(output, "\n");
>
> fprintf(output, _("Operating System\n"));
> diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
> index cb2ae9a..952d2bc 100644
> *** a/src/bin/psql/tab-complete.c
> --- b/src/bin/psql/tab-complete.c
> *************** psql_completion(char *text, int start, i
> *** 635,641 ****
> "\\lo_import", "\\lo_export", "\\lo_list", "\\lo_unlink",
> "\\o", "\\p", "\\password", "\\prompt", "\\pset", "\\q", "\
> \qecho", "\\r",
> "\\set", "\\t", "\\T",
> ! "\\timing", "\\unset", "\\x", "\\w", "\\z", "\\!", NULL
> };
>
> (void) end; /* not used */
> --- 635,641 ----
> "\\lo_import", "\\lo_export", "\\lo_list", "\\lo_unlink",
> "\\o", "\\p", "\\password", "\\prompt", "\\pset", "\\q", "\
> \qecho", "\\r",
> "\\set", "\\t", "\\T",
> ! "\\timing", "\\unset", "\\x", "\\w", "\\whoami", "\\z", "\\!", NULL
> };
>
> (void) end; /* not used */
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

This is a review for the \whoami patch (changed to \conninfo).

This review was done on the Feb 2 2010 version of the patch (rebased to
head) that reflects some of the feedback from -hackers on the initial
submission. The commitfest entry should be updated to reflect the most
recent version of this patch that David emailed to me.

Content & Purpose
========================
The patch adds a \conninfo command to psql to print connection information
for the current connection. The patch includes documentation updates but no
regression test changes. I don't see regression tests for other psql '\'
commands so I don't think they are required in this case either.

Usability Review
==========================

The initial discussion on -hackers recommened renaming the command to
\conninfo which was done.

One comment I have on the output format is that values (ie the database
name) are enclosed in double quotes but the values being quoted can contain
double quotes that are not being escaped. For example

Connected to database: "testing"er", user: "ssinger", port: "5432" via local
domain socket

(where my database name is testing"er ). Programs will have a hard time
parsing this. I'm not sure if this is a valid concern but I'm mentioning
it.

Initial Run
==============

Connecting both through tcp/ip and unix domain sockets produces valid
\conninfo output. The regression tests pass when the patch is applied.

Performance
=============

I see no performance implications of this patch.

Code & Nitpicking
================

in command.c you have the opening brace on the same line as the if. See
"if (host) {"
and the associated "else {"

The block " else if (strcmp(cmd, "conninfo") == 0)" is in between the
commands "\c" and "\cd" it looks like the commands are ordered
alphabetically. Wouldn't conninfo fit in after "\cd" but before "\copy"

In help.c you don't update the row count at the top of slashUsage() per the
comment you should increment it.

Other than those issues the patch looks fine.

Steve

On Sun, Jun 20, 2010 at 10:51 PM, Steve Singer <ssinger_pg(at)sympatico(dot)ca> wrote:
> One comment I have on the output format is that values (ie the database
> name) are enclosed in double quotes but the values being quoted can contain
> double quotes that are not being escaped.   For example
>
> Connected to database: "testing"er", user: "ssinger", port: "5432" via local
> domain socket
>
> (where my database name is testing"er ).  Programs will have a hard time
> parsing this.  I'm not sure if this is a valid concern but I'm mentioning
> it.

It seems like for user and database it might be sensible to apply
PQescapeIdentifier to the value before printing it. This will
double-quote it and escape any internal double-quotes appropriately.
The port is, I guess, being stored as a string, but doesn't it have to
be an integer? In which case, why quote it at all?

Is there really a point to the non-DSN format or should we just use
the DSN format always?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Jun 20, 2010 at 10:51 PM, Steve Singer <ssinger_pg(at)sympatico(dot)ca> wrote:
>> One comment I have on the output format is that values (ie the database
>> name) are enclosed in double quotes but the values being quoted can contain
>> double quotes that are not being escaped.

This is the same as standard practice in just about every other
message...

> It seems like for user and database it might be sensible to apply
> PQescapeIdentifier to the value before printing it.

I think this would actually be a remarkably bad idea in this particular
instance, because in the majority of cases psql does not apply
identifier dequoting rules to user and database names. What is printed
should be the same as what you'd need to give to \connect, for example.

> The port is, I guess, being stored as a string, but doesn't it have to
> be an integer? In which case, why quote it at all?

Agreed, no need for quotes there.

regards, tom lane

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Is there really a point to the non-DSN format or should we just use
> the DSN format always?

BTW, didn't have an opinion on that to start with, but after thinking
about it I'd turn it around. psql doesn't deal in DSN format anywhere
else, so why should it do so here? To make the point more obvious,
what's the justification for printing DSN format and not, say, JDBC URL
format? I'd vote for removing the DSN printout option, not the other
way round. If there was some mechanically readable format to offer to
print, it would be conninfo string format, which you can actually use
with psql if you have a mind to.

regards, tom lane

On Jun 21, 2010, at 9:00 AM, Tom Lane wrote:

> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Sun, Jun 20, 2010 at 10:51 PM, Steve Singer <ssinger_pg(at)sympatico(dot)ca> wrote:
>>> One comment I have on the output format is that values (ie the database
>>> name) are enclosed in double quotes but the values being quoted can contain
>>> double quotes that are not being escaped.
>
> This is the same as standard practice in just about every other
> message...
>
>> It seems like for user and database it might be sensible to apply
>> PQescapeIdentifier to the value before printing it.
>
> I think this would actually be a remarkably bad idea in this particular
> instance, because in the majority of cases psql does not apply
> identifier dequoting rules to user and database names. What is printed
> should be the same as what you'd need to give to \connect, for example.

So I'm not quite sure how the above two paragraphs resolve? Should the user/database names be quoted or not? I have a new version of this patch available which has incorporated the feedback to this point?

As an example of the current behavior, consider:

machack:machack:5432=# create database "foo""bar"
machack-# ;
CREATE DATABASE

[Sun Jul 18 12:14:49 CDT 2010]
machack:machack:5432=# \c foo"bar
unterminated quoted string
You are now connected to database "machack".

[Sun Jul 18 12:14:53 CDT 2010]
machack:machack:5432=# \c "foo"bar"
unterminated quoted string
You are now connected to database "machack".

[Sun Jul 18 12:14:59 CDT 2010]
machack:machack:5432=# \c "foo""bar"
You are now connected to database "foo"bar".

As you can see, the value passed to connect differs from the output in the "connected to database" string.

Regards,

David
--
David Christensen
End Point Corporation
david(at)endpoint(dot)com

On Jul 18, 2010, at 12:17 PM, David Christensen wrote:

>
> On Jun 21, 2010, at 9:00 AM, Tom Lane wrote:
>
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> On Sun, Jun 20, 2010 at 10:51 PM, Steve Singer <ssinger_pg(at)sympatico(dot)ca> wrote:
>>>> One comment I have on the output format is that values (ie the database
>>>> name) are enclosed in double quotes but the values being quoted can contain
>>>> double quotes that are not being escaped.
>>
>> This is the same as standard practice in just about every other
>> message...
>>
>>> It seems like for user and database it might be sensible to apply
>>> PQescapeIdentifier to the value before printing it.
>>
>> I think this would actually be a remarkably bad idea in this particular
>> instance, because in the majority of cases psql does not apply
>> identifier dequoting rules to user and database names. What is printed
>> should be the same as what you'd need to give to \connect, for example.
>
>
> So I'm not quite sure how the above two paragraphs resolve? Should the user/database names be quoted or not? I have a new version of this patch available which has incorporated the feedback to this point?
>
> As an example of the current behavior, consider:
>
> machack:machack:5432=# create database "foo""bar"
> machack-# ;
> CREATE DATABASE
>
> [Sun Jul 18 12:14:49 CDT 2010]
> machack:machack:5432=# \c foo"bar
> unterminated quoted string
> You are now connected to database "machack".
>
> [Sun Jul 18 12:14:53 CDT 2010]
> machack:machack:5432=# \c "foo"bar"
> unterminated quoted string
> You are now connected to database "machack".
>
> [Sun Jul 18 12:14:59 CDT 2010]
> machack:machack:5432=# \c "foo""bar"
> You are now connected to database "foo"bar".
>
> As you can see, the value passed to connect differs from the output in the "connected to database" string.

It's helpful when you attach said patch. This has been rebased to current HEAD.

Regards,

David
--
David Christensen
End Point Corporation
david(at)endpoint(dot)com

David Christensen <david(at)endpoint(dot)com> writes:
> machack:machack:5432=# \c "foo""bar"
> You are now connected to database "foo"bar".

What this is reflecting is that backslash commands have their own weird
rules for processing double quotes. What I was concerned about was that
double quotes in SQL are normally used for protecting mixed case, and
you don't need that for \c:

regression=# create database "FooBar";
CREATE DATABASE
regression=# \c foobar
FATAL: database "foobar" does not exist
Previous connection kept
regression=# \c FooBar
You are now connected to database "FooBar".
FooBar=#

The fact that there are double quotes around the database name in the
"You are now connected..." message is *not* meant to imply that that is
a valid double-quoted SQL identifier, either. It's just an artifact of
how we set off names in English-language message style. In another
language it might look like <<FooBar>> or some such.

My opinion remains that you should just print the user and database
names as-is, without trying to inject any quoting into the mix. You're
more likely to confuse people than help them if you do that.

regards, tom lane

On Jul 18, 2010, at 12:30 PM, Tom Lane wrote:

> David Christensen <david(at)endpoint(dot)com> writes:
>> machack:machack:5432=# \c "foo""bar"
>> You are now connected to database "foo"bar".
>
> What this is reflecting is that backslash commands have their own weird
> rules for processing double quotes. What I was concerned about was that
> double quotes in SQL are normally used for protecting mixed case, and
> you don't need that for \c:
>
> regression=# create database "FooBar";
> CREATE DATABASE
> regression=# \c foobar
> FATAL: database "foobar" does not exist
> Previous connection kept
> regression=# \c FooBar
> You are now connected to database "FooBar".
> FooBar=#
>
> The fact that there are double quotes around the database name in the
> "You are now connected..." message is *not* meant to imply that that is
> a valid double-quoted SQL identifier, either. It's just an artifact of
> how we set off names in English-language message style. In another
> language it might look like <<FooBar>> or some such.
>
> My opinion remains that you should just print the user and database
> names as-is, without trying to inject any quoting into the mix. You're
> more likely to confuse people than help them if you do that.

Okay, understood. Then consider my updated patch (just sent attached to a recent message) to reflect the desired behavior. (I'll update the commitfest patch entry when it shows up in the archives.)

Thanks,

David
--
David Christensen
End Point Corporation
david(at)endpoint(dot)com

On Jul 18, 2010, at 12:33 PM, David Christensen wrote:

>
> On Jul 18, 2010, at 12:30 PM, Tom Lane wrote:
>
>> David Christensen <david(at)endpoint(dot)com> writes:
>>> machack:machack:5432=# \c "foo""bar"
>>> You are now connected to database "foo"bar".
>>
>> What this is reflecting is that backslash commands have their own weird
>> rules for processing double quotes. What I was concerned about was that
>> double quotes in SQL are normally used for protecting mixed case, and
>> you don't need that for \c:
>>
>> regression=# create database "FooBar";
>> CREATE DATABASE
>> regression=# \c foobar
>> FATAL: database "foobar" does not exist
>> Previous connection kept
>> regression=# \c FooBar
>> You are now connected to database "FooBar".
>> FooBar=#
>>
>> The fact that there are double quotes around the database name in the
>> "You are now connected..." message is *not* meant to imply that that is
>> a valid double-quoted SQL identifier, either. It's just an artifact of
>> how we set off names in English-language message style. In another
>> language it might look like <<FooBar>> or some such.
>>
>> My opinion remains that you should just print the user and database
>> names as-is, without trying to inject any quoting into the mix. You're
>> more likely to confuse people than help them if you do that.
>
>
> Okay, understood. Then consider my updated patch (just sent attached to a recent message) to reflect the desired behavior. (I'll update the commitfest patch entry when it shows up in the archives.)

Updated the commitfest entry with the patch, updated the title to reflect the actual name of the command, and marked as ready for committer.

Regards,

David
--
David Christensen
End Point Corporation
david(at)endpoint(dot)com

On Sun, 18 Jul 2010, David Christensen wrote:

>
>
> It's helpful when you attach said patch. This has been rebased to current HEAD.

One minor thing I noticed in the updated patch.

You moved the '{' after the if(host) in command.c to it's own line(good) but
you used spaces instead of tabstops there, the same with the else.

>
> Regards,
>
> David
> --
> David Christensen
> End Point Corporation
> david(at)endpoint(dot)com
>
>
>
>

On Sun, Jul 18, 2010 at 2:00 PM, David Christensen <david(at)endpoint(dot)com> wrote:
> Updated the commitfest entry with the patch, updated the title to reflect the actual name of the command, and marked as ready for committer.

I took a look at this patch. One problem is that it doesn't handle
the case where there is no database connection (for example, shut down
the database with pg_ctl, then do select 1, then do \conninfo). I've
fixed that in the attached version.

However, I'm also wondering about the output format. I feel like it
would make sense to use a format similar to what we do for \c, which
looks like this:

You are now connected to database "%s".

It prints out more parameters if they've changed. The longest
possible version is:

You are now connected to database "%s" on host "%s" at port "%s" as user "%s".

My suggestion is that we use the same format, except (1) always
include all the components, since that's the point; (2) don't include
the word "now"; and (3) if there is no host, then print "via local
socket" rather than on host...port.... So where the current patch
prints:

Connected to database: "rhaas", user: "rhaas", port: 5432 via local
domain socket

I would propose to print instead:

You are connected to database "rhaas" via local socket as user "rhaas".

If people strongly prefer the way the patch does it now, I don't think
it's horrible... but it seems like it would be nicer to be somewhat
consistent with the existing message. Thoughts?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

On Jul 19, 2010, at 10:34 PM, Robert Haas wrote:

> On Sun, Jul 18, 2010 at 2:00 PM, David Christensen <david(at)endpoint(dot)com> wrote:
>> Updated the commitfest entry with the patch, updated the title to reflect the actual name of the command, and marked as ready for committer.
>
> I took a look at this patch. One problem is that it doesn't handle
> the case where there is no database connection (for example, shut down
> the database with pg_ctl, then do select 1, then do \conninfo). I've
> fixed that in the attached version.

Thanks, I hadn't considered that case.

> However, I'm also wondering about the output format. I feel like it
> would make sense to use a format similar to what we do for \c, which
> looks like this:
>
> You are now connected to database "%s".
>
> It prints out more parameters if they've changed. The longest
> possible version is:
>
> You are now connected to database "%s" on host "%s" at port "%s" as user "%s".
>
> My suggestion is that we use the same format, except (1) always
> include all the components, since that's the point; (2) don't include
> the word "now"; and (3) if there is no host, then print "via local
> socket" rather than on host...port.... So where the current patch
> prints:
>
> Connected to database: "rhaas", user: "rhaas", port: 5432 via local
> domain socket
>
> I would propose to print instead:
>
> You are connected to database "rhaas" via local socket as user "rhaas".
>
> If people strongly prefer the way the patch does it now, I don't think
> it's horrible... but it seems like it would be nicer to be somewhat
> consistent with the existing message. Thoughts?

+1 from me; I don't care what color the bikeshed is, as long as it gets the point across, which this does, and is consistent to boot.

Regards,

David
--
David Christensen
End Point Corporation
david(at)endpoint(dot)com

On Mon, Jul 19, 2010 at 11:41 PM, David Christensen <david(at)endpoint(dot)com> wrote:
>> I took a look at this patch.  One problem is that it doesn't handle
>> the case where there is no database connection (for example, shut down
>> the database with pg_ctl, then do select 1, then do \conninfo).  I've
>> fixed that in the attached version.
>
> Thanks, I hadn't considered that case.

For some reason, I end up crashing a lot of databases during
development (must be my lousy coding). So I've had occasion to run
across this, ahem, a few times...

> +1 from me; I don't care what color the bikeshed is, as long as it gets the point across, which this does, and is consistent to boot.

Great, committed that way.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

> I would propose to print instead:
>
> You are connected to database "rhaas" via local socket as user "rhaas".

One minor quibble here; you lose the ability to see which pg instance you're running on if there are multiple ones running on different local sockets, so maybe either the port or the socket path should show up here still.

Regards,

David
--
David Christensen
End Point Corporation
david(at)endpoint(dot)com

On Tue, Jul 20, 2010 at 12:02 AM, David Christensen <david(at)endpoint(dot)com> wrote:
>> I would propose to print instead:
>>
>> You are connected to database "rhaas" via local socket as user "rhaas".
>
>
> One minor quibble here; you lose the ability to see which pg instance you're running on if there are multiple ones running on different local sockets, so maybe either the port or the socket path should show up here still.

Doh. Will fix.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

On Tue, Jul 20, 2010 at 12:07 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Jul 20, 2010 at 12:02 AM, David Christensen <david(at)endpoint(dot)com> wrote:
>>> I would propose to print instead:
>>>
>>> You are connected to database "rhaas" via local socket as user "rhaas".
>>
>>
>> One minor quibble here; you lose the ability to see which pg instance you're running on if there are multiple ones running on different local sockets, so maybe either the port or the socket path should show up here still.
>
> Doh.  Will fix.

Something like the attached?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

On Jul 19, 2010, at 11:10 PM, Robert Haas wrote:

> On Tue, Jul 20, 2010 at 12:07 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Tue, Jul 20, 2010 at 12:02 AM, David Christensen <david(at)endpoint(dot)com> wrote:
>>>> I would propose to print instead:
>>>>
>>>> You are connected to database "rhaas" via local socket as user "rhaas".
>>>
>>>
>>> One minor quibble here; you lose the ability to see which pg instance you're running on if there are multiple ones running on different local sockets, so maybe either the port or the socket path should show up here still.
>>
>> Doh. Will fix.
>
> Something like the attached?

Looks good to me.

Regards,

David
--
David Christensen
End Point Corporation
david(at)endpoint(dot)com

On Tue, Jul 20, 2010 at 12:16 AM, David Christensen <david(at)endpoint(dot)com> wrote:
> On Jul 19, 2010, at 11:10 PM, Robert Haas wrote:
>
>> On Tue, Jul 20, 2010 at 12:07 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> On Tue, Jul 20, 2010 at 12:02 AM, David Christensen <david(at)endpoint(dot)com> wrote:
>>>>> I would propose to print instead:
>>>>>
>>>>> You are connected to database "rhaas" via local socket as user "rhaas".
>>>>
>>>>
>>>> One minor quibble here; you lose the ability to see which pg instance you're running on if there are multiple ones running on different local sockets, so maybe either the port or the socket path should show up here still.
>>>
>>> Doh.  Will fix.
>>
>> Something like the attached?
>
>
> Looks good to me.

OK, committed.

Thanks for the patch!

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

On Tue, Jul 20, 2010 at 11:14 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> OK, committed.

When I specify the path of the directory for the Unix-domain socket
as the host, \conninfo doesn't mention that this connection is based
on the Unix-domain socket. Is this intentional?

$ psql -h"/tmp" -c"\conninfo"
You are connected to database "postgres" on host "/tmp" at port "5432"
as user "postgres".

I expected that something like

You are connected to database "postgres" via local socket on
"/tmp" at port "5432" as user "postgres".

is output.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

On Wed, Jul 21, 2010 at 1:07 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Tue, Jul 20, 2010 at 11:14 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> OK, committed.
>
> When I specify the path of the directory for the Unix-domain socket
> as the host, \conninfo doesn't mention that this connection is based
> on the Unix-domain socket. Is this intentional?
>
> $ psql -h"/tmp" -c"\conninfo"
> You are connected to database "postgres" on host "/tmp" at port "5432"
> as user "postgres".
>
> I expected that something like
>
>    You are connected to database "postgres" via local socket on
> "/tmp" at port "5432" as user "postgres".

:-(

No, I didn't realize the host field could be used that way. It's true
that you get a fairly similar message from \c, but that's not exactly
intuitive either.

rhaas=# \c - - /tmp -
You are now connected to database "rhaas" on host "/tmp".

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

On Wed, Jul 21, 2010 at 7:29 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Jul 21, 2010 at 1:07 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Tue, Jul 20, 2010 at 11:14 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> OK, committed.
>>
>> When I specify the path of the directory for the Unix-domain socket
>> as the host, \conninfo doesn't mention that this connection is based
>> on the Unix-domain socket. Is this intentional?
>>
>> $ psql -h"/tmp" -c"\conninfo"
>> You are connected to database "postgres" on host "/tmp" at port "5432"
>> as user "postgres".
>>
>> I expected that something like
>>
>>    You are connected to database "postgres" via local socket on
>> "/tmp" at port "5432" as user "postgres".
>
> :-(
>
> No, I didn't realize the host field could be used that way.  It's true
> that you get a fairly similar message from \c, but that's not exactly
> intuitive either.
>
> rhaas=# \c - - /tmp -
> You are now connected to database "rhaas" on host "/tmp".

OK. The attached patch makes \conninfo command emit the following
message if the host begins with a slash:

$ psql -h/tmp -c"\conninfo"
You are connected to database "postgres" via local socket on
"/tmp" at port "5432" as user "postgres".

Similarly, it makes \c command emit the following message in that
case:

$ psql -hlocalhost -c"\c - - /tmp -"
You are now connected to database "postgres" via local socket on "/tmp".

Comments?

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

On Jul 21, 2010, at 8:48 PM, Fujii Masao wrote:

> On Wed, Jul 21, 2010 at 7:29 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Wed, Jul 21, 2010 at 1:07 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>> On Tue, Jul 20, 2010 at 11:14 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>> OK, committed.
>>>
>>> When I specify the path of the directory for the Unix-domain socket
>>> as the host, \conninfo doesn't mention that this connection is based
>>> on the Unix-domain socket. Is this intentional?
>>>
>>> $ psql -h"/tmp" -c"\conninfo"
>>> You are connected to database "postgres" on host "/tmp" at port "5432"
>>> as user "postgres".
>>>
>>> I expected that something like
>>>
>>> You are connected to database "postgres" via local socket on
>>> "/tmp" at port "5432" as user "postgres".
>>
>> :-(
>>
>> No, I didn't realize the host field could be used that way. It's true
>> that you get a fairly similar message from \c, but that's not exactly
>> intuitive either.
>>
>> rhaas=# \c - - /tmp -
>> You are now connected to database "rhaas" on host "/tmp".
>
> OK. The attached patch makes \conninfo command emit the following
> message if the host begins with a slash:
>
> $ psql -h/tmp -c"\conninfo"
> You are connected to database "postgres" via local socket on
> "/tmp" at port "5432" as user "postgres".
>
> Similarly, it makes \c command emit the following message in that
> case:
>
> $ psql -hlocalhost -c"\c - - /tmp -"
> You are now connected to database "postgres" via local socket on "/tmp".

If we print the local socket when it's been explicitly set via the host= param, why not display the actual socket path in the general local socket case?

Also, while we're still tweaking this patch, I've had a couple requests for the SSL status of the connection as well; does this seem like a generally useful parameter to display as well?

Regards,

David
--
David Christensen
End Point Corporation
david(at)endpoint(dot)com

On Wed, Jul 21, 2010 at 9:48 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Wed, Jul 21, 2010 at 7:29 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Wed, Jul 21, 2010 at 1:07 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>> On Tue, Jul 20, 2010 at 11:14 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>> OK, committed.
>>>
>>> When I specify the path of the directory for the Unix-domain socket
>>> as the host, \conninfo doesn't mention that this connection is based
>>> on the Unix-domain socket. Is this intentional?
>>>
>>> $ psql -h"/tmp" -c"\conninfo"
>>> You are connected to database "postgres" on host "/tmp" at port "5432"
>>> as user "postgres".
>>>
>>> I expected that something like
>>>
>>>    You are connected to database "postgres" via local socket on
>>> "/tmp" at port "5432" as user "postgres".
>>
>> :-(
>>
>> No, I didn't realize the host field could be used that way.  It's true
>> that you get a fairly similar message from \c, but that's not exactly
>> intuitive either.
>>
>> rhaas=# \c - - /tmp -
>> You are now connected to database "rhaas" on host "/tmp".
>
> OK. The attached patch makes \conninfo command emit the following
> message if the host begins with a slash:
>
>    $ psql -h/tmp -c"\conninfo"
>    You are connected to database "postgres" via local socket on
> "/tmp" at port "5432" as user "postgres".
>
> Similarly, it makes \c command emit the following message in that
> case:
>
>    $ psql -hlocalhost -c"\c - - /tmp -"
>    You are now connected to database "postgres" via local socket on "/tmp".
>
> Comments?

Should we be using is_absolute_path() here instead, as libpq does?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

On Wed, Jul 21, 2010 at 10:09 PM, David Christensen <david(at)endpoint(dot)com> wrote:
>
> On Jul 21, 2010, at 8:48 PM, Fujii Masao wrote:
>
>> On Wed, Jul 21, 2010 at 7:29 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> On Wed, Jul 21, 2010 at 1:07 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>>> On Tue, Jul 20, 2010 at 11:14 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>>> OK, committed.
>>>>
>>>> When I specify the path of the directory for the Unix-domain socket
>>>> as the host, \conninfo doesn't mention that this connection is based
>>>> on the Unix-domain socket. Is this intentional?
>>>>
>>>> $ psql -h"/tmp" -c"\conninfo"
>>>> You are connected to database "postgres" on host "/tmp" at port "5432"
>>>> as user "postgres".
>>>>
>>>> I expected that something like
>>>>
>>>>    You are connected to database "postgres" via local socket on
>>>> "/tmp" at port "5432" as user "postgres".
>>>
>>> :-(
>>>
>>> No, I didn't realize the host field could be used that way.  It's true
>>> that you get a fairly similar message from \c, but that's not exactly
>>> intuitive either.
>>>
>>> rhaas=# \c - - /tmp -
>>> You are now connected to database "rhaas" on host "/tmp".
>>
>> OK. The attached patch makes \conninfo command emit the following
>> message if the host begins with a slash:
>>
>>    $ psql -h/tmp -c"\conninfo"
>>    You are connected to database "postgres" via local socket on
>> "/tmp" at port "5432" as user "postgres".
>>
>> Similarly, it makes \c command emit the following message in that
>> case:
>>
>>    $ psql -hlocalhost -c"\c - - /tmp -"
>>    You are now connected to database "postgres" via local socket on "/tmp".
>
>
> If we print the local socket when it's been explicitly set via the host= param, why not display the actual socket path in the general local socket case?

Patch?

> Also, while we're still tweaking this patch, I've had a couple requests for the SSL status of the connection as well; does this seem like a generally useful parameter to display as well?

Yes. If we're going to have the command, we might as well get as much
mileage out of it as we reasonably can.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

On Thu, Jul 22, 2010 at 11:57 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Should we be using is_absolute_path() here instead, as libpq does?

Yes. The attached patch does that.

>> On Wed, Jul 21, 2010 at 10:09 PM, David Christensen <david(at)endpoint(dot)com> wrote:
>> If we print the local socket when it's been explicitly set via the host= param, why not display the actual socket path in the general local socket case?
>
> Patch?

Done. DEFAULT_PGSOCKET_DIR (i.e., /tmp) should be displayed in that
case, I think.

$ psql -c"\conninfo"
You are connected to database "postgres" via local socket on
"/tmp" at port "5432" as user "postgres".

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

On Wed, Jul 21, 2010 at 11:13 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Thu, Jul 22, 2010 at 11:57 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> Should we be using is_absolute_path() here instead, as libpq does?
>
> Yes. The attached patch does that.
>
>>> On Wed, Jul 21, 2010 at 10:09 PM, David Christensen <david(at)endpoint(dot)com> wrote:
>>> If we print the local socket when it's been explicitly set via the host= param, why not display the actual socket path in the general local socket case?
>>
>> Patch?
>
> Done. DEFAULT_PGSOCKET_DIR (i.e., /tmp) should be displayed in that
> case, I think.
>
>    $ psql -c"\conninfo"
>    You are connected to database "postgres" via local socket on
> "/tmp" at port "5432" as user "postgres".

Sorry for the slow response, I've been slightly buried.

I've committed this with some kibitzing, the most relevant bit of
which is that I changed "via local socket on" to "via local socket
in", which I think reads better.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company