RE: Psql meta-command conninfo+
От | Maiquel Grassi |
---|---|
Тема | RE: Psql meta-command conninfo+ |
Дата | |
Msg-id | CP8P284MB2496AAFB879ABC5B1CD01CF4EC532@CP8P284MB2496.BRAP284.PROD.OUTLOOK.COM обсуждение исходный текст |
Ответ на | Re: Psql meta-command conninfo+ (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
RE: Psql meta-command conninfo+
(Maiquel Grassi <grassi@hotmail.com.br>)
Re: Psql meta-command conninfo+ (Nathan Bossart <nathandbossart@gmail.com>) |
Список | pgsql-hackers |
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 existing meta-commands
>that provide certain columns conditionally.
I implemented your suggestion. Now, whenever the \conninfo+ command is
invoked, all columns will appear. Contextually inappropriate cases will return
NULL. I also adjusted the names of the columns related to SSL to make this
information clearer for the user. I haven't focused on documenting the
columns yet. I will do that soon.
>Could we pull some of this information from pg_stat_ssl instead of from
>libpq? The reason I suggest this is because I think it would be nice if
>the query that \conninfo+ uses could be copy/pasted as needed and not rely
>on hard-coded values chosen by the client.
I've been considering using the views "pg_stat_ssl" and "pg_stat_gssapi"; however,
I realized that dealing with version-related cases using them is more complicated.
Let me explain the reasons:
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 complexity in
maintaining the SQL. The central idea from the beginning has always been to show
the user all the information from \conninfo and extend it in \conninfo+. The absence
of the "compression" column in version 14 and above makes dealing with this even
more complicated, and not showing it seems to contradict \conninfo.
SSL support has been available since version 7.1 (see documentation); if there was
support before that, I can't say. In this regard, it may seem strange, but there are still
many legacy systems running older versions of PostgreSQL. Just yesterday, I assisted
a client who is still using PG 8.2. In these cases, using the "pg_stat_ssl" and
"pg_stat_gssapi" views would not be possible because they don't exist on the server.
I believe that psql should cover as many cases as possible when it comes to compatibility
with older versions (even those no longer supported). In this case, concerning SSL and
GSS, I think libpq is better prepared to handle this.
I may be mistaken in my statement and I welcome any better suggestions. For now, I've
maintained the implementation using libpq as it seems to be working well and is not
contradicting \conninfo. If you have any suggestions on how to work around the absence
of the "compression" column, we can reconsider how to implement it without using libpq.
Tests:
[postgres@localhost bin]$ ./psql -x -h 127.0.0.1 -p 5432
[postgres@localhost bin]$ ./psql -x -h 127.0.0.1 -p 5433
Thank you very much for your sugestions and help!
Maiquel Grassi.
Вложения
В списке pgsql-hackers по дате отправления: