Re: Fix output of zero privileges in psql - Mailing list pgsql-hackers

From Laurenz Albe
Subject Re: Fix output of zero privileges in psql
Date
Msg-id d799f996f422231a99655f1223667d6d887e4c95.camel@cybertec.at
Whole thread Raw
In response to Re: Fix output of zero privileges in psql  (Erik Wienhold <ewie@ewie.name>)
Responses Re: Fix output of zero privileges in psql
Re: Fix output of zero privileges in psql
List pgsql-hackers
On Sat, 2023-10-21 at 04:29 +0200, Erik Wienhold wrote:
> The attached v3 of my initial patch
> does that.  It also includes Laurenz' fix to no longer ignore \pset null
> (minus the doc changes that suggest using \pset null to distinguish
> between default and empty privileges because that's no longer needed).

Thanks!

I went over the patch, fixed some problems and added some more stuff from
my patch.

In particular:

  --- a/doc/src/sgml/ddl.sgml
  +++ b/doc/src/sgml/ddl.sgml
  @@ -2353,7 +2353,9 @@ GRANT SELECT (col1), UPDATE (col1) ON mytable TO miriam_rw;
     <para>
      If the <quote>Access privileges</quote> column is empty for a given
      object, it means the object has default privileges (that is, its
  -   privileges entry in the relevant system catalog is null).  Default
  +   privileges entry in the relevant system catalog is null).  The column shows
  +   <literal>(none)</literal> for empty privileges (that is, no privileges at
  +   all, even for the object owner — a rare occurrence).  Default
      privileges always include all privileges for the owner, and can include
      some privileges for <literal>PUBLIC</literal> depending on the object
      type, as explained above.  The first <command>GRANT</command>

This description of empty privileges is smack in the middle of describing
default privileges.  I thought that was confusing and moved it to its
own paragraph.

  --- a/src/bin/psql/describe.c
  +++ b/src/bin/psql/describe.c
  @@ -6718,7 +6680,13 @@ static void
   printACLColumn(PQExpBuffer buf, const char *colname)
   {
      appendPQExpBuffer(buf,
  -                     "pg_catalog.array_to_string(%s, E'\\n') AS \"%s\"",
  +                     "CASE\n"
  +                     "  WHEN %s IS NULL THEN ''\n"
  +                     "  WHEN pg_catalog.cardinality(%s) = 0 THEN '%s'\n"
  +                     "  ELSE pg_catalog.array_to_string(%s, E'\\n')\n"
  +                     "END AS \"%s\"",
  +                     colname,
  +                     colname, gettext_noop("(none)"),
                        colname, gettext_noop("Access privileges"));
   }

This erroneously displays NULL as empty string and subverts my changes.
I have removed the first branch of the CASE expression.

  --- a/src/test/regress/expected/psql.out
  +++ b/src/test/regress/expected/psql.out
  @@ -6663,3 +6663,97 @@ DROP ROLE regress_du_role0;
   DROP ROLE regress_du_role1;
   DROP ROLE regress_du_role2;
   DROP ROLE regress_du_admin;
  +-- Test empty privileges.
  +BEGIN;
  +WARNING:  there is already a transaction in progress

This warning is caused by a pre-existing error in the regression test, which
forgot to close the transaction.  I have added a COMMIT at the appropriate place.

  +ALTER TABLESPACE regress_tblspace OWNER TO CURRENT_USER;
  +REVOKE ALL ON TABLESPACE regress_tblspace FROM CURRENT_USER;
  +\db+ regress_tblspace
  +                                                List of tablespaces
  +       Name       |         Owner          |    Location     | Access privileges | Options |  Size   | Description
  +------------------+------------------------+-----------------+-------------------+---------+---------+-------------
  + regress_tblspace | regress_zeropriv_owner | pg_tblspc/16385 | (none)            |         | 0 bytes |
  +(1 row)

This test is not stable, since it contains the OID of the tablespace, which
is different every time.

  +ALTER DATABASE :"DBNAME" OWNER TO CURRENT_USER;
  +REVOKE ALL ON DATABASE :"DBNAME" FROM CURRENT_USER, PUBLIC;
  +\l :"DBNAME"
  +                                                        List of databases
  +    Name    |         Owner          | Encoding  | Locale Provider | Collate | Ctype | ICU Locale | ICU Rules |
Accessprivileges  

+------------+------------------------+-----------+-----------------+---------+-------+------------+-----------+-------------------
  + regression | regress_zeropriv_owner | SQL_ASCII | libc            | C       | C     |            |           |
(none)
  +(1 row)

This test is also not stable, since it depends on the locale definition
of the regression test database.  If you use "make installcheck", that could
be a different locale.

I think that these tests are not absolutely necessary, and the other tests
are sufficient.  Consequently, I took the simple road of removing them.

I also tried to improve the commit message.

Patch attached.

Yours,
Laurenz Albe

Attachment

pgsql-hackers by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: pg_ctl start may return 0 even if the postmaster has been already started on Windows
Next
From: Alexander Korotkov
Date:
Subject: Re: Removing unneeded self joins