On 11.04.2025 20:09, David G. Johnston wrote:
However, I do think we are at something committable, though I'd make
one, maybe two, changes to v8.
Let's return to this topic.
Valid until -> Password valid until: the timestamp value already
forces a wide column, adding the word Password to the
On 11.04.2025 20:09, David G. Johnston wrote:
However, I do think we are at something committable, though I'd make
one, maybe two, changes to v8.
Thank you for supporting this patch.
Valid until -> Password valid until: the timestamp value already
forces a wide column, adding the word Passwor
On Sun, Feb 9, 2025 at 2:11 AM Pavel Luzanov
wrote:
>
> I don't understand from new commitfest transition guidance
> what to do with status of commitfest entry in this case.
> May be it needs to be closed. And in a case I will be able to propose
> a new version, I will open a new entry.
>
> The c
Hello,
After reading thread "new commitfest transition guidance"[0],
and as patch author, I decided to write short summary for this
committfest entry[1].
Last patch has version 8, example output and code are here[2].
Proposed approach to \du command has not found positive responses
for several m
On 23.07.2024 15:53, Robert Haas wrote:
On Mon, Jul 22, 2024 at 5:19 PM Pavel Luzanov wrote:
Visible but inaccessible objects in system catalogs increase the volume
of command output unnecessarily. Why do I need to know the list of all
schemas in the database if I only have access to the public
On Mon, Jul 22, 2024 at 5:19 PM Pavel Luzanov wrote:
> Visible but inaccessible objects in system catalogs increase the volume
> of command output unnecessarily. Why do I need to know the list of all
> schemas in the database if I only have access to the public schema?
> The same applies to inacce
Robert,
Iam pleasedthatyouare payingso muchattentionto thispatch.
On 19.07.2024 16:26, Robert Haas wrote:
Second, I think that the threshold question for this patch is: will
users, on average, be happier if this patch gets committed? If the
answer is yes, then the patch should be committed, and
Hi Pavel,
First, thanks for your dedication to this effort. I always find it
hard to make time for things like psql backslash command improvements,
but I'm glad that we have people in our community who work on such
things.
Second, I think that the threshold question for this patch is: will
users,
On 16.07.2024 18:00, Robert Haas wrote:
On the question of display width, my personal opinion is that the
current patch is worse than what we have now.
Robert, David, thanks for the detailed explanation.
I tried to remember all the thoughts that led to this version of the patch.
So the main
On Tue, Jul 16, 2024 at 8:00 AM Robert Haas wrote:
> I'm starting to have some doubts about whether this effort is really
> worthwhile. It seems like what we have right now is a patch which uses
> both more horizontal space and more vertical space than the current
> implementation, without (IMHO)
On Tue, Jul 16, 2024 at 9:48 AM Pavel Luzanov wrote:
> Which version of the patch is currently under discussion?
>
> I believe we are talking about the latest v8 patch version. [1]
>
> 1.
> https://www.postgresql.org/message-id/5341835b-e7be-44dc-b6e5-400e9e3f3c64%40postgrespro.ru
Thanks. For so
On 16.07.2024 16:24, Robert Haas wrote:
Which version of the patch is currently under discussion?
I believe we are talking about the latest v8 patch version. [1]
1.https://www.postgresql.org/message-id/5341835b-e7be-44dc-b6e5-400e9e3f3c64%40postgrespro.ru
--
Pavel Luzanov
Postgres Professiona
On Tue, Jul 16, 2024 at 4:53 AM Pavel Luzanov wrote:
> On 15.07.2024 12:50, Rafia Sabih wrote:
> Well, it was just my opinion of how I would have liked it better, but
> of course you may decide against it, there is no strong feeling around
> it.
> And if you are on the fence with the opinion of ha
On 15.07.2024 12:50, Rafia Sabih wrote:
Well, it was just my opinion of how I would have liked it better, but
of course you may decide against it, there is no strong feeling around
it.
And if you are on the fence with the opinion of having them in normal
or extended mode, then maybe we can ask mo
On Sat, 13 Jul 2024 at 14:21, Pavel Luzanov wrote:
>
> On 12.07.2024 12:22, Rafia Sabih wrote:
>
> Other thoughts came to my mind, should we have this column in \du+
> instead, maybe connection limit too.
> I know in the current version we have all this in \du itself, but then
> all clubbed in one
On 12.07.2024 12:22, Rafia Sabih wrote:
Other thoughts came to my mind, should we have this column in \du+
instead, maybe connection limit too.
I know in the current version we have all this in \du itself, but then
all clubbed in one column. But now since
our table has got wider, it might be aest
On Fri, 12 Jul 2024 at 09:06, Pavel Luzanov wrote:
>
> On 11.07.2024 15:07, Rafia Sabih wrote:
>
> This looks much better than the current version.
>
> Thank you, for looking into this.
>
> Only thing is, I find
> the column name Valid until confusing. With that name I am in danger
> of taking it
On 11.07.2024 15:07, Rafia Sabih wrote:
This looks much better than the current version.
Thank you, for looking into this.
Only thing is, I find
the column name Valid until confusing. With that name I am in danger
of taking it as the role's validity and not the passwords'.
How about naming it
On Thu, 6 Jun 2024 at 23:10, Pavel Luzanov wrote:
>
> On 06.06.2024 17:29, Robert Haas wrote:
>
> I think the first of these special interpretations is unnecessary and
> should be removed. It seems pretty clear what 0 means.
>
> Agree.
> There is an additional technical argument for removing this
On 10.06.2024 09:25, Kyotaro Horiguchi wrote:
I guess that in English, when written as "'Login' = 'yes/no'", it can
be easily understood. However, in Japanese, "'ログイン' = 'はい/いいえ'"
looks somewhat awkward and is a bit difficult to understand at a
glance. "'ログイン' = '可/不可'" (equivalent to "Login is
At Sat, 8 Jun 2024 14:09:11 -0400, Robert Haas wrote in
> On Sat, Jun 8, 2024 at 10:02 AM Pavel Luzanov
> wrote:
> > Therefore, I think the current patch offers a better version of the \du
> > command.
> > However, I admit that these improvements are not enough to accept the patch.
> > I would
On Sat, Jun 8, 2024 at 10:02 AM Pavel Luzanov wrote:
> Therefore, I think the current patch offers a better version of the \du
> command.
> However, I admit that these improvements are not enough to accept the patch.
> I would like to hear other opinions.
Hmm, I don't think I quite agree with th
On 07.06.2024 15:35, Robert Haas wrote:
This seems unobjectionable to me. I am not sure whether it is better
than the current verison, or whether it is what we want. But it seems
reasonable.
I consider this patch as a continuation of the work on \drg command,
when it was decided to remove the
On Thu, Jun 6, 2024 at 5:10 PM Pavel Luzanov wrote:
> Agree.
> There is an additional technical argument for removing this replacement.
> I don't like explicit cast to text of the "Connection limit" column.
> Without 'Not allowed' it is no longer required.
> Value -1 can be replaced by NULL with a
On 06.06.2024 17:29, Robert Haas wrote:
I think the first of these special interpretations is unnecessary and
should be removed. It seems pretty clear what 0 means.
Agree.
There is an additional technical argument for removing this replacement.
I don't like explicit cast to text of the "Connect
On Thu, Jun 6, 2024 at 5:08 AM Pavel Luzanov wrote:
> But now there are no changes in pg_roles. Just a special interpretation
> of the two values of the "Connection limit" column:
> 0 - Now allowed (changed from 'No connections')
> -1 - empty string
I think the first of these special interpret
On 16.04.2024 09:15, Pavel Luzanov wrote:
On 16.04.2024 01:06, David G. Johnston wrote:
At this point I'm on board with retaining the \dr charter of simply being
an easy way to access the detail exposed in pg_roles with some display
formatting but without any attempt to convey how the system use
On 14.05.2024 19:03, Robert Haas wrote:
I think we should go back to the v4 version of this patch, minus the
(ignored) stuff.
Thank you for looking into this.
I can assume that you support the idea of changing pg_roles. It's great.
By the way, I have attached a separate thread[1] about pg_role
On Tue, May 14, 2024 at 9:03 AM Robert Haas wrote:
> On Tue, Apr 16, 2024 at 3:06 AM Pavel Luzanov
> wrote:
> > As for the Login column and its values.
> > I'm not sure about using "Can" instead of "yes" to represent true.
> > In other psql commands, boolean values are always shown as yes/no.
>
On Tue, Apr 16, 2024 at 3:06 AM Pavel Luzanov wrote:
> As for the Login column and its values.
> I'm not sure about using "Can" instead of "yes" to represent true.
> In other psql commands, boolean values are always shown as yes/no.
> NULL instead of false might be possible, but I'd rather check i
Hi,
On 14.04.2024 05:02, Wen Yi wrote:
I think we can change the output like this:
postgres=# \du
List of roles
Role name | Login | Attributes | Password | Valid until | Connection limit
---+---+-+--+-+-
On 16.04.2024 01:06, David G. Johnston wrote:
At this point I'm on board with retaining the \dr charter of simply being an
easy way to access the detail exposed in pg_roles with some display formatting
but without any attempt to convey how the system uses said information.
Without changing p
On Sun, Feb 18, 2024 at 4:14 AM Pavel Luzanov
wrote:
> 2. Tom's advise:
>
> Not sure it's worth worrying about
>
> Show real values for 'Valid until' and 'Connection limit' without any hints.
>
>
At this point I'm on board with retaining the \dr charter of simply being
an easy way to access the d
On Sat, Apr 13, 2024 at 7:02 PM Wen Yi wrote:
> I think we can change the output like this:
>
> postgres=# \du
> List of roles
> Role name | Login | Attributes | Password | Valid until | Connection
> limit
>
> ---+---+-+--+
hnston"<david.g.johns...@gmail.com>;
Cc: "Tom Lane"<t...@sss.pgh.pa.us>;"Jim
Nasby"<jim.na...@gmail.com>;"Robert
Haas"<robertmh...@gmail.com>;"pgsql-hackers"<pgsql-hackers@lists.postgresql.org>;
Subject: Re: Things I don't like
I think the output need to change, like this:
postgres=# \du+
List of roles
Role name | Login | Attributes | Password | Valid until | Connection limit |
Description
---+---+-+--+-+--+
On 17.02.2024 00:37, David G. Johnston wrote:
On Mon, Feb 12, 2024 at 2:29 PM Pavel Luzanov
wrote:
regress_du_role1 | no| Inherit | no| 2024-12-31
00:00:00+03(invalid) | 50 | Group role without password but with
valid until
regress_du_role2 | yes |
On 17.02.2024 00:44, Tom Lane wrote:
"David G. Johnston" writes:
Per the recent bug report, we should probably add something like (ignored)
after the 50 connections for role1 since they are not allowed to login so
the value is indeed ignored. It is ignored to zero as opposed to unlimited
for t
"David G. Johnston" writes:
> Per the recent bug report, we should probably add something like (ignored)
> after the 50 connections for role1 since they are not allowed to login so
> the value is indeed ignored. It is ignored to zero as opposed to unlimited
> for the Superuser so maybe a differen
On Mon, Feb 12, 2024 at 2:29 PM Pavel Luzanov
wrote:
> regress_du_role1 | no| Inherit | no| 2024-12-31
> 00:00:00+03(invalid) | 50 | Group role without password but
> with valid until
> regress_du_role2 | yes | Inherit | yes |
On 13.02.2024 00:29, Pavel Luzanov wrote:
The changes are split into two patches.
0001 - pg_roles view. I plan to organize a new thread for discussion.
Please see it here:
https://www.postgresql.org/message-id/db1d94ba-1e6e-4e86-baff-91e6e79071c1%40postgrespro.ru
--
Pavel Luzanov
Postgres Prof
On 28.01.2024 22:51, Pavel Luzanov wrote:
I'll think about it and try to implement in the next patch version
within a few days.
Sorry for delay.
Please look at v4.
I tried to implement all of David's suggestions.
The only addition - "Login" column. I still thinks this is important
information
On 28.01.2024 22:51, Pavel Luzanov wrote:
On 23.01.2024 04:18, Tom Lane wrote:
I think expecting the pg_roles view to change for this is problematic.
You can't have that in the back branches, so with this patch psql
will show something different against a pre-17 server than later
versions. At b
On Sun, Jan 28, 2024 at 1:29 PM Pavel Luzanov
wrote:
> I'd suggest pulling out this system view change into its own patch.
>
>
> But within this thread or new one?
>
>
>
Thread. The subject line needs to make clear we are proposing changing a
system view.
The connection limit can be set to 0. W
On 23.01.2024 01:59, David G. Johnston wrote:
The attribute names correspond to the keywords of the CREATE ROLE command.
The attributes are listed in the same order as in the documentation.
(I think that the LOGIN attribute should be moved to the first place,
both in the document
On 23.01.2024 04:18, Tom Lane wrote:
I think expecting the pg_roles view to change for this is problematic.
You can't have that in the back branches, so with this patch psql
will show something different against a pre-17 server than later
versions. At best, that's going to be confusing.
I've b
On Sun, Jan 21, 2024 at 2:35 PM Pavel Luzanov
wrote:
> List of roles
> Role name | Attributes | Password? | Valid until | Connection
> limit
> ---+-+---++--
> admin | INHERIT
On Mon, Jan 22, 2024 at 6:26 PM Tom Lane wrote:
> I wrote:
> > I think expecting the pg_roles view to change for this is problematic.
> > You can't have that in the back branches, so with this patch psql
> > will show something different against a pre-17 server than later
> > versions. At best,
I wrote:
> I think expecting the pg_roles view to change for this is problematic.
> You can't have that in the back branches, so with this patch psql
> will show something different against a pre-17 server than later
> versions. At best, that's going to be confusing.
Actually, even more to the po
Pavel Luzanov writes:
> Another approach based on early suggestions.
I think expecting the pg_roles view to change for this is problematic.
You can't have that in the back branches, so with this patch psql
will show something different against a pre-17 server than later
versions. At best, that's
On Sun, Jan 21, 2024 at 2:35 PM Pavel Luzanov
wrote:
> Another approach based on early suggestions.
>
> The Attributes column includes only the enabled logical attributes.
> Regardless of whether the attribute is enabled by default or not.
>
>
> The attribute names correspond to the keywords of
2024-01 Commitfest.
Hi, This patch has a CF status of "Needs Review" [1], but it seems
there were CFbot test failures last time it was run [2]. Please have a
look and post an updated version if necessary.
==
[1] https://commitfest.postgresql.org/46/4738/
[2] https://cirrus-ci.com/github/postg
Another approach based on early suggestions.
The Attributes column includes only the enabled logical attributes.
Regardless of whether the attribute is enabled by default or not.
This changes the current behavior, but makes it clearer: everything
that is enabled is displayed. This principle is ea
On 03.01.2024 02:37, Jim Nasby wrote:
Some attributes are arguably important enough to warrant their own
column. The most obvious is NOLOGIN, since those roles are generally
used for a very different purpose than LOGIN roles. SUPERUSER might be
another candidate (though, I much prefer a dedic
On 02.01.2024 22:38, Robert Haas wrote:
To add to that a bit, I would probably never ask a user to give me the
output of \du to troubleshoot some issue. I would either ask them for
pg_dumpall -g output, or I'd ask them to give me the raw contents of
pg_authid. That's because I know that either o
On 1/2/24 1:38 PM, Robert Haas wrote:
But to try to apply that concept
here means that we suppose the user knows whether the default is
INHERIT or NOINHERIT, whether the default is BYPASSRLS or NOBYPASSRLS,
etc. And I'm just a little bit skeptical of that assumption. Per
On Tue, Jan 2, 2024 at 1:46 PM Tom Lane wrote:
> True, although if you aren't happy with the current state then what
> you actually need to construct is a SQL command to set a *different*
> state from what \du is saying. Going from LOGIN to NOLOGIN or vice
> versa can also be non-obvious. So you
Robert Haas writes:
> My thought was that such people probably need to interpret LOGIN and
> NOLOGIN into their preferred language either way, but if \du displays
> something else, then they also need to mentally construct a reverse
> mapping, from whatever string is showing up there to the corres
On Tue, Jan 2, 2024 at 1:17 PM Tom Lane wrote:
> Mmm ... maybe. I think those of us who are native English speakers
> may overrate the intelligibility of SQL keywords to those who aren't.
> So I'm inclined to feel that preserving translatability of the
> role property descriptions is a good thing
Robert Haas writes:
> I wonder if we shouldn't try to display the roles's properties using
> SQL keywords rather than narrating. Someone can be confused by "No
> connections" but "CONNECTION LIMIT 0" is pretty hard to mistake;
> likewise "LOGIN" or "NOLOGIN" seems clear enough.
Mmm ... maybe. I
On Thu, Jun 22, 2023 at 8:50 PM Tom Lane wrote:
> * It seems weird that some attributes are described in the negative
> ("Cannot login", "No inheritance"). I realize that this corresponds
> to the defaults, so that a user created by CREATE USER with no options
> shows nothing in the Attributes co
On 30.12.2023 17:33, Isaac Morland wrote:
Would it make sense to make the column non-nullable and always set it
to infinity when there is no expiry?
A password is not required for roles. In many cases, external
authentication is used in ph_hba.conf.
I think it would be strange to have 'infini
On Sat, 30 Dec 2023 at 09:23, Pavel Luzanov
wrote:
> I think that writing the value "infinity" in places where there is no
> value is
> not a good thing. This hides the real value of the column. In addition,
> there is no reason to set "infinity" when the password is always valid with
> default
Now I'm ready for discussion.
On 23.06.2023 03:50, Tom Lane wrote:
Nearby I dissed psql's \du command for its incoherent "Attributes"
column [1]. It's too late to think about changing that for v16,
but here's some things I think we should consider for v17:
* It seems weird that some attributes
On 23.06.2023 03:50, Tom Lane wrote:
* On a purely presentation level, how did we possibly arrive
at the idea that the connection-limit and valid-until properties
deserve their own lines in the Attributes column while the other
properties are comma-separated? That makes no sense whatsoever,
nor
On 23.06.2023 03:50, Tom Lane wrote:
Nearby I dissed psql's \du command for its incoherent "Attributes"
column [1]. It's too late to think about changing that for v16,
but here's some things I think we should consider for v17:
If there are no others willing, I am ready to take up this topic. T
66 matches
Mail list logo
