Alvaro Herrera writes:
> On 2025-Feb-22, Alvaro Herrera wrote:
>
>> Also, there's a bunch of "(char *)" casts that are 100% due to
>> printTableAddCell() taking a char * instead of const char * for the cell
>> value. That seems a bit silly, we should change that.
>
> Ah, but the problem is that
On 2025-Feb-22, Alvaro Herrera wrote:
> Also, there's a bunch of "(char *)" casts that are 100% due to
> printTableAddCell() taking a char * instead of const char * for the cell
> value. That seems a bit silly, we should change that.
Ah, but the problem is that most of the input cells there come
On 2025-Feb-21, Sami Imseih wrote:
> > If we want to include 'role' in this output, what I'd propose is to
> > have \conninfo issue "SHOW role", which is accepted by every server
> > version. If it fails (say because we're in an aborted transaction),
> > just omit that row from the output.
>
> v
> If we want to include 'role' in this output, what I'd propose is to
> have \conninfo issue "SHOW role", which is accepted by every server
> version. If it fails (say because we're in an aborted transaction),
> just omit that row from the output.
v37- would have handled this as the list of PQ pa
Sami Imseih writes:
>> Maybe keeping track of 'role' via ParameterStatus messages is a good
>> idea for reasons unrelated to this patch -- maybe it can be useful for
>> applications to be aware of role changes -- but I'm not 100% sure about
>> that, and in particular I'm not sure how heavy the pro
> Maybe keeping track of 'role' via ParameterStatus messages is a good
> idea for reasons unrelated to this patch -- maybe it can be useful for
> applications to be aware of role changes -- but I'm not 100% sure about
> that, and in particular I'm not sure how heavy the protocol traffic is
> going
>You don't get "There were only 99 Luftballons" or any such nonsense, and I
>don't see why \conninfo gets to play different rules. So I got rid of
>\conninfo+.
>From my perspective across this, I support this approach.
Regards,
Maiquel.
Alvaro Herrera writes:
> Do people hate the question marks?
They feel not per our usual style. I think the output
would be equally readable without them.
Otherwise, +1 for this general approach. I agree we can just
kick the current output format to the curb.
regards, t
I suggest the attached, which gets 99% there with 10% of the
complexity, and has \conninfo (no plus sign) output this:
Connection Information
Parámetro │ Valor
───┼
Base de Datos │ alvherre
Client Use
Hi,
On Mon, Jan 20, 2025 at 6:34 PM Maiquel Grassi
wrote:
> >That leads me to also wonder why don't we change \conninfo to have this
> >tabular behavior instead of creating a separate command for it. Why do
> >we need to keep the existing form of \conninfo? To me it seems strictly
> >less usef
>That leads me to also wonder why don't we change \conninfo to have this
>tabular behavior instead of creating a separate command for it. Why do
>we need to keep the existing form of \conninfo? To me it seems strictly
>less useful, as it is harder to read.
Here, you're suggesting that it would b
On 2025-Jan-17, Sami Imseih wrote:
> > Wait a second, why do we have these here? Aren't they already in
> > \dconfig?
>
> \dconfig is generated by querying pg_settings and this
> requires a halthy connection. The parameters being proposed with
> \conninfo+ are set in libpq by the server [1] and
> Wait a second, why do we have these here? Aren't they already in
> \dconfig?
\dconfig is generated by querying pg_settings and this
requires a halthy connection. The parameters being proposed with
\conninfo+ are set in libpq by the server [1] and can be retrieved
even if the connection breaks.
Hi,
On Thu, Jan 16, 2025 at 6:01 PM Alvaro Herrera
wrote:
> On 2025-Jan-16, Hunaid Sohail wrote:
>
> > server_encoding | UTF8
> > server_version| 18devel
> > client_encoding | UTF8
> > session_authorization | hunaid
> > standard_conforming
On 2025-Jan-16, Hunaid Sohail wrote:
> server_encoding | UTF8
> server_version| 18devel
> client_encoding | UTF8
> session_authorization | hunaid
> standard_conforming_strings | on
> DateStyle | ISO, MDY
> scram_itera
Hi,
I have attached 3 new patches v37-000* which display the
\conninfo+ output as 2 columns "Parameter" and "Value".
The other 2 patches are:
1. A new libpq function, PQparameterNames, which returns
names of parameters reported by the server.
2. Mark role as GUC_REPORT.
All these patches include
On Tue, 14 Jan 2025 at 08:51, Alvaro Herrera wrote:
>
> On 2025-Jan-14, Hunaid Sohail wrote:
>
> > I've tried the approach and attached the output. Does this look good?
>
> Hmm, I'm not sure I like the third column particularly; it's noisy to
> have on all the time. I'd leave that for \conninfo+
On 2025-Jan-14, Hunaid Sohail wrote:
> I'm not attaching the patch as it requires some formatting.
Remember pgindent formats code in bulk. A quick useful workflow is to
do that first, apply manual adjustments next, run pgindent again
afterwards.
> I've tried the approach and attached the output
Hi,
On Mon, Jan 13, 2025 at 4:12 PM Dean Rasheed
wrote:
> I don't like the 3-table format either. I think it should be a single
> table.
>
> The trouble with v35 is that it produces 1 row with lots of columns,
> which is pretty unreadable unless expanded mode is used. So I think we
> should just
On Mon, 13 Jan 2025 at 08:44, Alvaro Herrera wrote:
>
> > IMO, we should continue with v35 and add all parameters from
> > PQparameterStatus,
> > as Sami suggested. The names themselves are informative enough.
>
> IMO we need more opinions. Maybe enough other people are not as unhappy
> about the
On 2025-Jan-10, Hunaid Sohail wrote:
> IMO, we should continue with v35 and add all parameters from
> PQparameterStatus,
> as Sami suggested. The names themselves are informative enough.
IMO we need more opinions. Maybe enough other people are not as unhappy
about the three-table solution.
--
Hi,
On Fri, Jan 10, 2025 at 1:50 AM Sami Imseih wrote:
> > If we go with the 3 column format, then we will just
> > have a bunch of repeated values for Category, which
> > looks cluttered, IMO.
>
> "cluttered" is maybe the wrong description. I meant the output
> will look overwhelming due to the
> If we go with the 3 column format, then we will just
> have a bunch of repeated values for Category, which
> looks cluttered, IMO.
"cluttered" is maybe the wrong description. I meant the output
will look overwhelming due to the repeated values :)
Regards,
Sami
> I dislike totally discarding the category information we have available to
> us. How about making a long output with just three columns in non-expanded
> mode. Setting, Value, Category ?
We can probably make due without a category as
the name of the setting is informative enough, right?
If
On Thu, Jan 9, 2025 at 12:28 PM Sami Imseih wrote:
> > v35 seems fine to me from a UI standpoint; I suggest we move forward
> > with that.
>
> I am also OK with moving forward with a single \conninfo+, but
> I think we should include all parameters in [1] as part of the output.
> These are the pa
> v35 seems fine to me from a UI standpoint; I suggest we move forward
> with that.
I am also OK with moving forward with a single \conninfo+, but
I think we should include all parameters in [1] as part of the output.
These are the parameters the server reports back to the client. I think
they are
On 2024-Dec-26, Maiquel Grassi wrote:
> The previous version was good to go and ready for a commit as soon as
> the final review is finalized. About David’s proposal, I’m still a
> little unsure, but it seems like it has a lot of potential. What do
> you all think? If it’s a strong direction to ex
> If we loop through conn->pstatus, we will be bypassing the official API.
> The list is of type pgParameterStatus, which is an internal struct defined in
> libpq-int.h.
> As the file's header warns, including this file can lead to issues. Or am I
> missing something?
you're right about the warn
Hi,
After looking at this ever more today, I think "Server Parameter Settings"
> is confusing as well. I think "Connection Status" instead of
> "Current Status" as is defined in v36 will work better.
> This way we will have "Connection Info" and "Connection Status".
> Connection Status will reflec
>> I think "Connection Encryption" seems unnecessary here as
>> well and it could be added to "Connection Information".
>
>
> Yes, we can do that, but we’d be left with two tables:
> "Connection Information" and "Server Parameter Settings". Does that work?
After looking at this ever more today, I
Hi,
Thank you for your valuable feedback.
1/ I am having a hard time making sense of the section "Current Status"
> None of the values in that section can be changed in the lifetime
> of a connection. The description "Current Status" makes it
> seem like they can change.
>
Any suggestions?
2/ C
I spent time reviewing v36 today and I have some comments.
Overall I think it's in better shape and the value of being
able to get this information from a single command meta-command
is really useful.
But I have some comments. Sorry if I am re-hashing things
that have already been discussed.
1/ I
>Hi,
>
>I provided a patch a month ago with a new approach as suggested by David.
>Unfortunately, it didn't get any attention in the November CF.
>
>I would appreciate your feedback on whether we should proceed with this new
>approach or stick with the previous one.
>
>Regards,
>Hunaid Sohail
--/
Hi,
I provided a patch a month ago with a new approach as suggested by David.
Unfortunately, it didn't get any attention in the November CF.
I would appreciate your feedback on whether we should proceed with this new
approach or stick with the previous one.
Regards,
Hunaid Sohail
Hi,
I have attached a new patch that incorporates the approach suggested by
David. The documentation has also been updated.
$ bin/psql "port=5430 sslmode=disable dbname=postgres" -x -h localhost
psql (18devel)
Type "help" for help.
postgres=# \conninfo+
Connection Information
-[ RECORD 1 ]+
On Sun, Oct 6, 2024 at 11:17 PM Hunaid Sohail wrote:
>
> PQpass - no need
>
I would include this as presence/absence.
I concur on all of the rest.
>
> For PQparameterStatus, some parameters are already used.
> server_version and application_name were already discussed and removed in
> v12 and
Hi David,
Thank you for your feedback.
On Fri, Oct 4, 2024 at 11:56 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> It seems to me a more useful definition for what this command should print
> out is basically the entire contents of:
>
> https://www.postgresql.org/docs/current/libpq-
On Thursday, October 3, 2024, Hunaid Sohail wrote:
>
>
> Authenticated User: The name of the user returned by PQuser(), indicating
> the user who initiated or authenticated the current database connection.
> Session User: The session user's name, which is initially the same as the
> authenticated
Hi,
On Thu, Oct 3, 2024 at 1:39 PM Maiquel Grassi wrote:
> >I thought it would be nice to have a description that tells how both
> >Session and Authenticated users differ. IMHO *only* a reference to
> >PQuser() doesn't say much, but others might be ok with it. So let's see
> >what the other revi
>I thought it would be nice to have a description that tells how both
>Session and Authenticated users differ. IMHO *only* a reference to
>PQuser() doesn't say much, but others might be ok with it. So let's see
>what the other reviewers say.
Hi everyone,
I believe the difference between Session an
On 02.10.24 06:48, Hunaid Sohail wrote:
> Should I revert to the v34 docs for Session User, or is it fine as is?
What I tried to say is that the current description is a bit vague ---
specially "Authenticated User".
> Authenticated User: The name of the user returned by PQuser()
> Session User
Hi,
On Tue, Oct 1, 2024 at 10:50 AM Jim Jones wrote:
> Right. I meant "Session User"
>
> > Authenticated User: The name of the user returned by PQuser()
> > Session User: The session user's name.
>
Should I revert to the v34 docs for Session User, or is it fine as is?
Session User: The session
On 01.10.24 06:27, Hunaid Sohail wrote:
> There are two users in the conninfo+: 'session' and 'authenticated'.
> Both are documented.
Right. I meant "Session User"
> Authenticated User: The name of the user returned by PQuser()
> Session User: The session user's name.
Thanks
--
Jim
Hi,
On Mon, Sep 30, 2024 at 11:16 PM Jim Jones
wrote:
> On 26.09.24 09:15, Hunaid Sohail wrote:
> > This patch renames "Current User" to "Authenticated User" as suggested
> > by me in my last email. I have also updated the documentation
> accordingly.
>
> Could you perhaps in the documentation e
Hi
On 26.09.24 09:15, Hunaid Sohail wrote:
> This patch renames "Current User" to "Authenticated User" as suggested
> by me in my last email. I have also updated the documentation accordingly.
Could you perhaps in the documentation elaborate a bit more on the
difference between "Current User" and
Hi,
This patch renames "Current User" to "Authenticated User" as suggested by
me in my last email. I have also updated the documentation accordingly.
On Tue, Sep 17, 2024 at 4:53 PM Hunaid Sohail wrote:
> We can update the docs as follows:
> Authenticated User: The name of the user returned by
Hi,
On Mon, Sep 16, 2024 at 8:31 PM Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2024-Sep-16, Jim Jones wrote:
> >> * The value of "Current User" does not match the function current_user()
> >> --- as one might expcect. It is a little confusing, as there is no
> >> mention of "Current User"
Alvaro Herrera writes:
> On 2024-Sep-16, Jim Jones wrote:
>> * The value of "Current User" does not match the function current_user()
>> --- as one might expcect. It is a little confusing, as there is no
>> mention of "Current User" in the docs. In case this is the intended
>> behaviour, could you
On 2024-Sep-16, Jim Jones wrote:
> * The value of "Current User" does not match the function current_user()
> --- as one might expcect. It is a little confusing, as there is no
> mention of "Current User" in the docs. In case this is the intended
> behaviour, could you please add it to the docs?
On 16.09.24 08:51, Hunaid Sohail wrote:
> I have attached a new patch that now prints all info in tabular format
> for \conninfo+. I have also made the table output dynamic, so if the
> connection uses SSL, the columns in the table will expand accordingly.
>
It looks much cleaner now.
> I have a
Hi,
On Sat, Sep 14, 2024 at 10:50 PM Tom Lane wrote:
> Alvaro Herrera writes:
> > I don't understand why this is is printing half the information in
> > free-form plain text and the other half in tabular format. All these
> > items that you have in the free-form text lines should be part of th
Alvaro Herrera writes:
> I don't understand why this is is printing half the information in
> free-form plain text and the other half in tabular format. All these
> items that you have in the free-form text lines should be part of the
> table, I think.
+1, that was my reaction as well. I can se
On 2024-Sep-14, Hunaid Sohail wrote:
> I agree that both messages should be printed together. IMO the message
> "You are connected to database..." should be printed at the top, no?
> Because it shows important info that the user may be interested to see
> first. Then we can combine the ssl message
Hi Jim,
On Fri, Sep 13, 2024 at 4:27 PM Jim Jones wrote:
> I just noticed that messages' order has been slightly changed. The
> message "You are connected to database "postgres" as user "hunaid" via
> socket in "/tmp" at port "5430" used to be printed after the table, and
> now it is printed bef
On 13.09.24 06:49, Hunaid Sohail wrote:
>
> $ bin/psql --port=5430 postgres
> psql (18devel)
> Type "help" for help.
>
> postgres=# \conninfo+
> You are connected to database "postgres" as user "hunaid" via socket
> in "/tmp" at port "5430".
> Co
Hi,
On Thu, Sep 12, 2024 at 4:08 PM Jim Jones wrote:
> It may look like this, but it is a single record --- mind the header "-[
> RECORD 1 ]+-".
> psql was called in expanded mode:
>
> > $ /home/pgsql-17devel/bin/psql -x -p 5432
>
> "-x" or "--expanded"
>
> Example:
>
> $
On 11.09.24 13:35, Hunaid Sohail wrote:
> Hi Jim,
>
> On Wed, Sep 11, 2024 at 3:03 PM Jim Jones
> wrote:
>
> Thanks for working on this.
>
> Any particular reason for the design change? In v28 it returned a
> table
> with a single row and multiple columns --- one column per
>
Hi Jim,
On Wed, Sep 11, 2024 at 3:03 PM Jim Jones wrote:
> Thanks for working on this.
>
> Any particular reason for the design change? In v28 it returned a table
> with a single row and multiple columns --- one column per attribute. But
> now it returns multiple rows. In this case, I was expect
On 11.09.24 10:16, Hunaid Sohail wrote:
I have made the requested changes. Now output is returned in tabular
form. Indentation/whitespace issues are fixed.
$bin/psql --port=5430 postgres
postgres=# \conninfo+
You are connected to database "postgres" as user "hunaid" via socket
in "/tmp" at p
Hi,
On Tue, Sep 10, 2024 at 9:16 PM Alvaro Herrera
wrote:
> On 2024-Sep-10, Jim Jones wrote:
>
> > Is \conninfo+ no longer supposed to return the results in tabular form?
> > At least it wasn't the case till v28.
>
> I suspect the reason it's no longer a table is that it was previously a
> query
On 2024-Sep-10, Jim Jones wrote:
> Is \conninfo+ no longer supposed to return the results in tabular form?
> At least it wasn't the case till v28.
I suspect the reason it's no longer a table is that it was previously a
query (which is easily printed as a table by calling printQuery) and now
it's
On 10.09.24 06:32, Hunaid Sohail wrote:
>
> I have attached a rebased patch.
Thanks.
Is \conninfo+ no longer supposed to return the results in tabular form?
At least it wasn't the case till v28.
$ /usr/local/postgres-dev/bin/psql -d postgres -h 0 -c "\conninfo+"
You are connected to database
Hi,
I have attached a rebased patch.
Regards,
Hunaid Sohail
On Mon, Sep 9, 2024 at 6:22 PM Jim Jones wrote:
> Hi Hunaid
>
> On 02.08.24 14:11, Hunaid Sohail wrote:
> >
> > I have also edited the documentation and added it to the patch. Please
> > let me know if any changes are required.
> >
>
Hi Hunaid
On 02.08.24 14:11, Hunaid Sohail wrote:
>
> I have also edited the documentation and added it to the patch. Please
> let me know if any changes are required.
>
I just wanted to review this patch again but v30 does not apply
=== Applying patches on top of PostgreSQL commit ID
d8df7ac5c
Hi,
I have read the entire thread discussion. I understood the importance of
this enhancement related to /conninfo+ meta command. I really appreciate
the efforts of Maiquel and suggestions made by the reviewers. According to
best of my understanding, libpq API should be used instead of creating
se
>From a quick skim of the latest messages in this thread, it sounds like
there are a couple of folks who think \conninfo (and consequently
\conninfo+) should only report values from the libpq API. I think they
would prefer server-side information to be provided via a system view or
maybe an entire
On Wed, May 29, 2024 at 12:37:21PM +, Maiquel Grassi wrote:
> Is there someone willing to help me with this development and guide the
> patch so that it can be committed one day?
>From a quick skim of the latest messages in this thread, it sounds like
there are a couple of folks who think \con
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
> "\conn
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 th
> 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 ap
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 ap
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 conce
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. T
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
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 mod
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 mod
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.
I
> 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 f
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, thoug
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 Unix
> 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 function
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(&buf,
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: v24-0001-psql-meta-command-conninfo-
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 yo
>. 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(&buf,
" NULL AS \"%s\",\n"
" NULL AS \"%s\",\n"
" NULL AS \"%s\",\n"
" N
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(&buf,
" 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/ Fo
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 in
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 det
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 deta
> 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 u
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 you
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 W
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
1 - 100 of 145 matches
Mail list logo
