Hi,
Is there someone willing to help me with this development and guide the patch
so that it can be committed one day?
Regards,
Maiquel.
> The original \conninfo was designed to report values from the libpq API
> about what libpq connected to. And the convention in psql is that "+"
> provide more or less the same information but a bit more. So I think it
> is wrong to make "\conninfo+" something fundamentally different than
>
On 04.04.24 18:15, Maiquel Grassi wrote:
Well, I can revert \conninfo to its original state and keep \conninfo+
as it is, perhaps removing the application name, as I believe everything
else is important for a DBA/SysAdmin. Do you think we can proceed
with the patch this way? I am open to ideas
> The point about application_name is a valid one. I guess it's there
> because it's commonly given from the client side rather than being set
>server-side, even though it's still a GUC. Arguably we could remove it
> from \conninfo+, and claim that nothing that shows up in \dconfig should
> also
On 2024-Apr-04, Peter Eisentraut wrote:
> But I don't really see the point of this. The information you are querying
> is already available in various system views. This proposal is just a
> shorthand for a collection of various random things some people like to see.
> Like, by what reason is
Hi!
(v29)
I left the command \conninfo in its original form.
I removed the 'Application Name' column from the \conninfo+ command.
Thanks,
Maiquel Grassi.
v29-0001-psql-meta-command-conninfo-plus.patch
Description: v29-0001-psql-meta-command-conninfo-plus.patch
>> The existing \conninfo command gets its values from libpq APIs. You are
>> changing all of this to make a server query, which is a totally
>> different thing. If we wanted to take a change like this, I don't think
>> it should be reusing the \conninfo command.
FWIW, I agree with Peter's
Maiquel Grassi writes:
>> The existing \conninfo command gets its values from libpq APIs. You are
>> changing all of this to make a server query, which is a totally
>> different thing. If we wanted to take a change like this, I don't think
>> it should be reusing the \conninfo command.
FWIW, I
The existing \conninfo command gets its values from libpq APIs. You are
changing all of this to make a server query, which is a totally
different thing. If we wanted to take a change like this, I don't think
it should be reusing the \conninfo command.
But I don't really see the point of this.
The existing \conninfo command gets its values from libpq APIs. You are
changing all of this to make a server query, which is a totally
different thing. If we wanted to take a change like this, I don't think
it should be reusing the \conninfo command.
But I don't really see the point of
Hi folks,
(v28)
I made a modification to a variable in the 'host' column in the archive
'describe.c'.
Test:
[postgres@localhost ~]$ /home/pgsql-17devel/bin/psql -x -p 5432
psql (17devel, server 15.6)
Type "help" for help.
postgres=# \conninfo
You are connected to database "postgres" as user
Building the docs fail for v26. The error is:
ref/psql-ref.sgml:1042: element member: validity error : Element term is not
declared in member list of possible children
^
I am able to build up to v24 before the was replaced with
I tested building with a
Building the docs fail for v26. The error is:
ref/psql-ref.sgml:1042: element member: validity error : Element term is not
declared in member list of possible children
^
I am able to build up to v24 before the was replaced with
I tested building with a
Hello Sami,
(v26)
> Here is an example [1] where the session information functions are
> referenced.
> The public doc for this example is in [2].
> Something similar can be done here. For example:
> The session user's name; see the session_user()
> function in
> for more details.
> Here I considered your suggestion (Sami and Álvaro's). However, I haven't yet
> added the links for the functions system_user(), current_user(), and
> session_user().
> 'm not sure how to do it. Any suggestion on how to create/add the link?
Here is an example [1] where the session information
Amigos, boa tarde!
(v25)
>if (pset.version >= 14)
> one thing;
>else if (pset.version > 90500)
> second thing;
> else
> third thing;
>
>This also appears where you add the GSSAPI columns; and it's also in the
>final part where you append the FROM clause,
Database:
The database name of the connection.
Authenticated User:
The authenticated database user of the connection.
Socket Directory:
The Unix socket directory of the connection. NULL if host or hostaddr are
specified.
Host:
The host name or address of the connection. NULL if a
> That minor point aside, I disagree with Sami about repeating the docs
> for system_user() here. I would just say "The authentication data
> provided for this connection; see the function system_user() for more
> details."
+1. FWIW; Up the thread [1], I did mention we should link to the
Hello
Yeah, that's what I meant about the translations, thanks.
Two more comments,
- You don't need a two-level conditional here
if (pset.sversion >= 90500)
{
if (pset.sversion < 14)
appendPQExpBuffer(,
Hi!
(v24)
> I meant those columns to be just examples, but this should be applied to
> all the other columns in the output as well.
Applied the translation to all columns.
Regards,
Maiquel Grassi.
v24-0001-psql-meta-command-conninfo-plus.patch
Description:
On 2024-Mar-31, Maiquel Grassi wrote:
> Yes Álvaro, I have already appointed you as the patch reviewer.
> It's true, even before publishing it on Commifest, you have
> already provided good ideas and guidance.
Thanks.
> I adjusted the translation syntax for the SSL and GSSAPI columns.
> After
>. However,
> I didn't complete item 4. I'm not sure, but I believe that linking it to the
> documentation
> could confuse the user a bit. I chose to keep the descriptions as they were.
> However, if
> you have any ideas on how we could outline it, let me know and perhaps we can
> implement it.
Note that, in the patch as posted, the column names are not
translatable. In order to be translatable, the code needs to do
something like
appendPQExpBuffer(,
" NULL AS \"%s\",\n"
" NULL AS \"%s\",\n"
" NULL AS \"%s\",\n"
" NULL
Hello,
Note that, in the patch as posted, the column names are not
translatable. In order to be translatable, the code needs to do
something like
appendPQExpBuffer(,
" NULL AS \"%s\",\n"
" NULL AS \"%s\",\n"
" NULL AS \"%s\",\n"
> For the current patch, I have a few more comments.
> 1/ The output should be reorganized to show the fields that are part of
> “conninfo” first.
> With regards to the documentation. I think it's a good idea that every field
> has an
> description. However, I have some comments:
> 1/
Thank you for the updated patch.
First and foremost, thank you very much for the review.
> The initial and central idea was always to keep the metacommand
> "\conninfo" in its original state, that is, to preserve the string as it is.
> The idea of "\conninfo+" is to expand this to include more
Hi Sami!
(v21)
First and foremost, thank you very much for the review.
> 1/ I looked through other psql-meta commands and the “+” adds details but
> does not change output format. In this patch, conninfo and conninfo+
> have completely different output. The former is a string with all the
Hi,
Thanks for working on this.
I have a few comments about the current patch.
1/ I looked through other psql-meta commands and the “+” adds details but
does not change output format. In this patch, conninfo and conninfo+
have completely different output. The former is a string with all the
> Hi Nathan!
>
> Sorry for the delay, I was busy with other professional as well as personal
> activities.
> I made all the changes you suggested. I removed the variables and started
> using
> views "pg_stat_ssl" and "pg_stat_gssapi". I handled the PostgreSQL versioning
> regarding the views
On Thu, Feb 29, 2024 at 10:02:21PM +, Maiquel Grassi wrote:
> Sorry for the delay. I will make the adjustments as requested soon.
Looking forward to it.
//
Hi Nathan!
Sorry for the delay, I was busy with other professional as well as personal
activities.
I made all the changes
Hi Maiquel,
On Thu, Feb 29, 2024 at 10:02:21PM +, Maiquel Grassi wrote:
> Sorry for the delay. I will make the adjustments as requested soon.
We have only a few weeks left before feature-freeze for v17. Do you think
you will be able to send an updated patch soon?
--
Nathan Bossart
Amazon
On Thu, Feb 29, 2024 at 10:02:21PM +, Maiquel Grassi wrote:
> Sorry for the delay. I will make the adjustments as requested soon.
Looking forward to it.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Sat, Feb 17, 2024 at 02:53:43PM +, Maiquel Grassi wrote:
>> The "pg_stat_ssl" view is available from >= PG 9.5, and the "pg_stat_gssapi"
>> view is
>> available from >= PG 12. The "compression" column was removed from the
>> "pg_stat_ssl" from >= PG 14. All of these cases introduce greater
On Sat, Feb 17, 2024 at 02:53:43PM +, Maiquel Grassi wrote:
> The "pg_stat_ssl" view is available from >= PG 9.5, and the "pg_stat_gssapi"
> view is
> available from >= PG 12. The "compression" column was removed from the
> "pg_stat_ssl" from >= PG 14. All of these cases introduce greater
Hi!
(v19)
Adjusted the description of each column in the documentation as promised.
I used the existing documentation as a basis for each SQL function used,
as well as for functions and views related to SSL and GSSAPI (documentation).
If you can validate, I appreciate it.
Regards,
Maiquel
Hi Nathan!
(v18)
>I might be alone on this, but I think this command should output the same
>columns regardless of the version, whether it's using SSL, etc. and just
>put NULL in any that do not apply. IMHO that would simplify the code and
>help prevent confusion. Plus, I'm not aware of any
Hi!
>7) -h 0.0.0.0 - As you mentioned, this is one of the cases where host
>and "server address" differ.
> I am not sure if it is an issue. Perhaps the other reviewers might
>have an opinion on it
>$ /usr/local/postgres-dev/bin/psql -x -U postgres -h 0.0.0.0 -c
>"\conninfo+" -c "\conninfo"
Thanks for your work on this. I haven't been keeping up with the
discussion, but I took a quick look at the latest patch.
+
+"Database", "Authenticated User", "System User" (only for PostgreSQL
16 or higher),
+"Current User", "Session User", "Backend PID", "Server
On 15.02.24 23:16, Maiquel Grassi wrote:
>
> Hi!
>
> (v16)
>
> In this version, I made a small adjustment to the indentation
> of the \conninfo code and described the columns as returned
> by \conninfo+ as suggested by Jim Jones.
>
>
I've performed the following tests with v16:
1)
Hi!
(v16)
In this version, I made a small adjustment to the indentation
of the \conninfo code and described the columns as returned
by \conninfo+ as suggested by Jim Jones.
Regards,
Maiquel Grassi.
v16-0001-psql-meta-command-conninfo-plus.patch
Description:
>v14 applies cleanly and the SSL info is now shown as previously
>suggested. Here is a more comprehensive test:
>
>
>$ /usr/local/postgres-dev/bin/psql -x "\
>host=server.uni-muenster.de
>hostaddr=172.19.42.1
>user=jim dbname=postgres
>sslrootcert=server-certificates/server.crt
>
On 12.02.24 15:16, Maiquel Grassi wrote:
>
> (v14)
>
>
v14 applies cleanly and the SSL info is now shown as previously
suggested. Here is a more comprehensive test:
$ /usr/local/postgres-dev/bin/psql -x "\
host=server.uni-muenster.de
hostaddr=172.19.42.1
user=jim dbname=postgres
Hi,
On 12.02.2024 17:16, Maiquel Grassi wrote:
The "if (db == NULL)" has been removed, as well as the message inside
it. To always maintain the same error messages, I changed the
validation of "\conninfo" to match the validation used for
"\conninfo+". Therefore, now "\conninfo" and
>I found that \conninfo and \conninfo+ act differently when the connection is
>broken.
>I used pg_terminate_backend function from another session to terminate an open
>psql session.
>After that, \conninfo does not see the connection break (surprisingly!), and
>\conninfo+ returns an error:
>
>Database | postgres
>[...]
>Host | 127.0.0.1
>Encryption | SSL
>Protocol | PQsslAttribute(protocol)
>Cipher | PQsslAttribute(cipher)
>Compression| PQsslAttribute(compression)
>
>When GSS, like this
>
>Database | postgres
>Hmm, I noticed that this would call printSSLInfo() and printGSSInfo()
>after listConnectionInformation. It would be much better to show these
>in tabular format as well and remove the calls to printSSL/GSSInfo.
>
>I propose additional columns to the same \conninfo+ table; when SSL,
>like this:
>
Hmm, I noticed that this would call printSSLInfo() and printGSSInfo()
after listConnectionInformation. It would be much better to show these
in tabular format as well and remove the calls to printSSL/GSSInfo.
I propose additional columns to the same \conninfo+ table; when SSL,
like this:
>Hi Nathan
>
>On 09.02.24 03:41, Nathan Bossart wrote:
>
>> Separately, does
>> the server version really belong here? I'm not sure I would consider that
>> to be connection information.
>>
>I tend to agree with you. The info there wouldn't hurt, but perhaps the
>client version would be a better
Hi Pavel!
>The patch v10 build ends with a warning:
>$ make -j --silent
>describe.c:911:1: warning: no previous prototype for
>‘listConnectionInformation’ [-Wmissing-prototypes]
> 911 | listConnectionInformation()
| ^
>About terms.
I resolved this in v11. I had
>Sorry if this has been brought up, but I noticed that some of the
>information is listed below the result set:
>
> postgres=# \conninfo+
>Current Connection Information
> -[ RECORD 1 ]--+-
> Database | postgres
> Authenticated User | nathan
Hi, Maiquel!
The patch v10 build ends with a warning:
$ make -j --silent
describe.c:911:1: warning: no previous prototype for
‘listConnectionInformation’ [-Wmissing-prototypes]
911 | listConnectionInformation()
| ^
About terms.
postgres@postgres(17.0)=# \x
Hi Nathan
On 09.02.24 03:41, Nathan Bossart wrote:
> Separately, does
> the server version really belong here? I'm not sure I would consider that
> to be connection information.
>
I tend to agree with you. The info there wouldn't hurt, but perhaps the
client version would be a better fit.
--
Sorry if this has been brought up, but I noticed that some of the
information is listed below the result set:
postgres=# \conninfo+
Current Connection Information
-[ RECORD 1 ]--+-
Database | postgres
Authenticated User | nathan
On 08.02.24 21:37, Erik Wienhold wrote:
>> Modifiers such as + or S in \dS are not covered by autocompletion.
>> src/bin/psql/tab-complete.c only specifies backslash commands in their
>> basic form (without modifiers).
>>
>> (\dS actually autocompletes to \ds to my surprise)
>>
>Aha... I never
Hi Erik
On 08.02.24 21:37, Erik Wienhold wrote:
> Modifiers such as + or S in \dS are not covered by autocompletion.
> src/bin/psql/tab-complete.c only specifies backslash commands in their
> basic form (without modifiers).
>
> (\dS actually autocompletes to \ds to my surprise)
>
Aha... I never
>On 2024-02-08 20:37 +0100, Jim Jones wrote:
>> One thing I just noticed. The psql autocomplete feature does not suggest
>> the new + option of \conninfo. For instance, when typing "\connin[TAB]"
>> it automatically autocompletes to "\conninfo ". I guess it should also
>> be included in this
> v8 no longer throws a permission denied error for non-superusers - it is
> IMHO much nicer this way.
>
> $ /usr/local/postgres-dev/bin/psql postgres -p 5432 -h 127.0.0.1 -U jim
> psql (17devel)
> Type "help" for help.
>
> postgres=# \x
> Expanded display is on.
> postgres=# \conninfo+
> Current
On 2024-02-08 20:37 +0100, Jim Jones wrote:
> One thing I just noticed. The psql autocomplete feature does not suggest
> the new + option of \conninfo. For instance, when typing "\connin[TAB]"
> it automatically autocompletes to "\conninfo ". I guess it should also
> be included in this patch.
On 08.02.24 16:50, Maiquel Grassi wrote:
> Hi Jim,
> Thank you for your support on this patch!
> As I believe in its usability, I have been dedicating efforts to make
> it really interesting.
> I hadn't thought about the permissioning issue for
> "unix_socket_directories". I appreciate that.
> I
> On 07.02.24 21:13, Maiquel Grassi wrote:
>>
>> I believe in v7 patch we have a quite substantial meta-command feature.
>>
>>
> Thanks for implementing this. I find it very handy.
>
> I was just wondering if a "permission denied" error for non-superusers
> is the best choice for "\conninfo+":
>
>
> Hi,
> On 07.02.2024 23:13, Maiquel Grassi wrote:
> Regarding the "system_user" function, as it is relatively new, I added
> the necessary handling to avoid conflicts with versions lower than version 16.
> Yes, that's rights.
>
> A couple of doubts about the implementation details.
> But
Hi Maiquel
On 07.02.24 21:13, Maiquel Grassi wrote:
>
> I believe in v7 patch we have a quite substantial meta-command feature.
>
>
Thanks for implementing this. I find it very handy.
I was just wondering if a "permission denied" error for non-superusers
is the best choice for "\conninfo+":
Hi,
On 07.02.2024 23:13, Maiquel Grassi wrote:
Regarding the "system_user" function, as it is relatively new, I added
the necessary handling to avoid conflicts with versions lower than
version 16.
Yes, that's rights.
A couple of doubts about the implementation details.
But keep in mind
> Hi, Maiquel!
>
> On 07.02.2024 17:47, Maiquel Grassi wrote:
> "Also, it seems that the verbose parameter in the listConnectionInformation
> is unnecessary."
> Could you point out exactly the line or code snippet you are referring to?
> +bool
> +listConnectionInformation(const char *pattern,
Hi,Maiquel!
On 07.02.2024 17:47, Maiquel Grassi wrote:
"Also, it seems that the verbose parameter in the
listConnectionInformation is unnecessary." Could you point out exactly
the line or code snippet you are referring to?
+bool
+listConnectionInformation(const char *pattern,*bool verbose*)
This is a good idea about extended connection info.
On 07.02.2024 07:13, Maiquel Grassi wrote:
SELECT
...
current_user AS "User",
This will be inconsistent with \conninfo.
\conninfo returns authenticated user (PQuser), not the current_user.
It might be worth showing current_user,
On 2024-02-07 05:13 +0100, Maiquel Grassi wrote:
> On Tue, Feb 06, 2024 at 09:45:54PM +, Maiquel Grassi wrote:
> > My initial idea has always been that they should continue to appear
> > because \conninfo+ should show all the things that \conninfo shows and
> > add more
This is a good idea about extended connection info.
On 07.02.2024 07:13, Maiquel Grassi wrote:
SELECT
...
current_user AS "User",
This will be inconsistent with \conninfo.
\conninfo returns authenticated user (PQuser), not the current_user.
It might be worth showing current_user,
On 2024-02-07 05:13 +0100, Maiquel Grassi wrote:
> On Tue, Feb 06, 2024 at 09:45:54PM +, Maiquel Grassi wrote:
> > My initial idea has always been that they should continue to appear
> > because \conninfo+ should show all the things that \conninfo shows and
> > add more information. I
On Tue, Feb 06, 2024 at 09:45:54PM +, Maiquel Grassi wrote:
> My initial idea has always been that they should continue to appear
> because \conninfo+ should show all the things that \conninfo shows and
> add more information. I think that's the purpose of the 'plus.' Now we're
> on
On Tue, Feb 06, 2024 at 09:45:54PM +, Maiquel Grassi wrote:
> My initial idea has always been that they should continue to appear
> because \conninfo+ should show all the things that \conninfo shows and
> add more information. I think that's the purpose of the 'plus.' Now we're
> on a better
On Tue, Feb 06, 2024 at 03:06:05PM -0600, Nathan Bossart wrote:
> On Tue, Feb 06, 2024 at 08:52:09PM +, Maiquel Grassi wrote:
>> I made the adjustment in the code and updated the patch. I believe this
>> is the format suggested by you all. Would this be it?
>
> I was thinking
On Tue, Feb 06, 2024 at 08:52:09PM +, Maiquel Grassi wrote:
> I made the adjustment in the code and updated the patch. I believe this
> is the format suggested by you all. Would this be it?
I was thinking something more like
SELECT pg_catalog.current_database() AS "Database",
On Tue, Feb 06, 2024 at 03:06:05PM -0600, Nathan Bossart wrote:
> On Tue, Feb 06, 2024 at 08:52:09PM +, Maiquel Grassi wrote:
>> I made the adjustment in the code and updated the patch. I believe this
>> is the format suggested by you all. Would this be it?
>
> I was thinking something more
On Tue, Feb 06, 2024 at 08:52:09PM +, Maiquel Grassi wrote:
> I made the adjustment in the code and updated the patch. I believe this
> is the format suggested by you all. Would this be it?
I was thinking something more like
SELECT pg_catalog.current_database() AS "Database",
On 2024-02-06 19:19 +0100, Nathan Bossart wrote:
> On Tue, Feb 06, 2024 at 05:27:01PM +, Maiquel Grassi wrote:
> > postgres=# \conninfo+
> > Current Connection Information
> >Attribute| Value
> > +
> > Database | postgres
> >
On 2024-02-06 19:19 +0100, Nathan Bossart wrote:
> On Tue, Feb 06, 2024 at 05:27:01PM +, Maiquel Grassi wrote:
> > postgres=# \conninfo+
> > Current Connection Information
> >Attribute| Value
> > +
> > Database | postgres
> > User
On Tue, Feb 06, 2024 at 05:27:01PM +, Maiquel Grassi wrote:
> I'm seeking to improve the \conninfo meta-command in psql. Currently, it
> provides limited information about the current connection. I believe that
> expanding it using the concept of "plus" [+] could ease the work of DBAs,
>
78 matches
Mail list logo
