Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qCj6q-0001UL-B8 for pgsql-hackers@arkaria.postgresql.org; Fri, 23 Jun 2023 15:54:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1qCj5p-0002xY-Q6 for pgsql-hackers@arkaria.postgresql.org; Fri, 23 Jun 2023 15:53:01 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qCj5p-0002xM-8J; Fri, 23 Jun 2023 15:53:01 +0000 Received: from mail-lf1-x12c.google.com ([2a00:1450:4864:20::12c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qCj5i-0001yR-Db; Fri, 23 Jun 2023 15:52:59 +0000 Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-4f76a0a19d4so1069992e87.2; Fri, 23 Jun 2023 08:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687535572; x=1690127572; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Q47AfFlM0YlWPUGzUwGZIh7wF2lwDEvk1f+OTqwol5o=; b=CKnn6Q29tOoYYqcrBSuCWQN94qPA2InFeob18ohoOwIb8ky6t4DlBDs2pfTVh2GViF YUfG+GPfZKYAiI/PZ+iVU+ZFJnYvN2WLYBVbLc3uRZ8e1kpoXeNzFJgeJM4YA50hqIBM wZWK1mLSc74oQltk6j8HHbPu09qn82erroYMyZvLWJUBBBsIZnwFhpjg/opBYcSxLNqM kvgSo5/ofbRrjKeLP0NqxCCgIuiuuicUNbcGVJb1IECyM2Gna3hld6e9GKigKtfRNHEq UIzt9owKyFf1yCUXlgZ9Uk2azl2wFB/sKBV255GkqIQLJRdGiTIMy9DhF4fLBPS7QlrB RVhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687535572; x=1690127572; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Q47AfFlM0YlWPUGzUwGZIh7wF2lwDEvk1f+OTqwol5o=; b=jc0avCM0WxMUf0ZJFdbkAGEmt4LubDR9PtUKr+bm1rASqXnr7WyQxVygBB7zmuDs2s +8FjMpLlzirdxSncgHa9yoN6W/ZJbiXjesV/DLU8Rvv4TBksUnMFU44jUwGgM8v5RI+3 NyJAMvLW0S+u9o0+4P9v2j6SxB7UvcXhvaMbL5YdEyGQ5q2qIFiBHu8doUtgDxFkwiTR ER0ak4/2pa93CJhV6QRKKt+ryIrrIin4FwXUYwJjeIhDb3+ojAoIY8HSz562HQcjKuHx cXgwyhy0/H5+B4CX6cJhkKmphOL2zKps2moG1zSRRndlllY4J6vvPVoCsjgEwUCJBYMe TopA== X-Gm-Message-State: AC+VfDwYSQeIwAtVw1769MSuWEuxXO3pWqOMpSM5nWR+OauqnnHyP3Tq Fg6JAdXW3biEkJ7KpAhtrRXi7S48FWDlRNGVmNU= X-Google-Smtp-Source: ACHHUZ79qPCjyXoyOmWjo+zA0eSzmPo4weeBlfTGD0XyLAEQkxAtnVns3kPc4LAO8i9SK8v6dSyO0yRMicS7KKBE0f0= X-Received: by 2002:ac2:4992:0:b0:4f8:421f:cd37 with SMTP id f18-20020ac24992000000b004f8421fcd37mr3991933lfl.56.1687535571467; Fri, 23 Jun 2023 08:52:51 -0700 (PDT) MIME-Version: 1.0 References: <1525117.1680628353@sss.pgh.pa.us> <1575395.1680629866@sss.pgh.pa.us> <1831161.1680703111@sss.pgh.pa.us> <2977612.1683131109@sss.pgh.pa.us> <39e7431c-1224-ab05-c67c-68f4cf625442@postgrespro.ru> <6b64c59a-fe41-bb07-d0cd-856896412b00@postgresql.org> <7aa3d663-1ea9-de0d-c13a-cbce83902214@postgrespro.ru> <2aa2bbb9-d8cb-cddf-875f-49b2634525c1@postgresql.org> <4128935.1687478926@sss.pgh.pa.us> In-Reply-To: <4128935.1687478926@sss.pgh.pa.us> From: "David G. Johnston" Date: Fri, 23 Jun 2023 08:52:34 -0700 Message-ID: Subject: Re: psql: Add role's membership options to the \du+ command To: Tom Lane Cc: "Jonathan S. Katz" , Pavel Luzanov , Robert Haas , David Zhang , "pgsql-hackers@lists.postgresql.org" , rmt@lists.postgresql.org, horikyota.ntt@gmail.com Content-Type: multipart/alternative; boundary="0000000000004881f905fecdfed0" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000004881f905fecdfed0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 22, 2023 at 5:08=E2=80=AFPM Tom Lane wrote: > "Jonathan S. Katz" writes: > > On 6/15/23 2:47 PM, David G. Johnston wrote: > >> Robert - can you please comment on what you are willing to commit in > >> order to close out your open item here. My take is that the design fo= r > >> this, the tabular form a couple of emails ago (copied here), is > >> ready-to-commit, just needing the actual (trivial) code changes to be > >> made to accomplish it. > > > Can we resolve this before Beta 2?[1] The RMT originally advised to try > > to resolve before Beta 1[2], and this seems to be lingering. > > At this point I kinda doubt that we can get this done before beta2 > either, but I'll put in my two cents anyway: > > * I agree that the "tabular" format looks nicer and has fewer i18n > issues than the other proposals. > As you are on board with a separate command please clarify whether you mean the tabular format but still with newlines, one row per grantee, or the table with one row per grantor-grantee pair. I still like using newlines here even in the separate meta-command. > > * Personally I could do without the "empty" business, but that seems > unnecessary in the tabular format; an empty column will serve fine. > I disagree, but not strongly. I kinda expected you to be on the side of "why are we discussing a situation that should just be prohibited" though. > * I also agree with Pavel's comment that we'd be better off taking > this out of \du altogether and inventing a separate \d command. > Maybe "\drg" for "display role grants"? > Just to be clear, the open item fix proposal is to remove the presently broken (due to it showing duplicates without any context) "member of" array in \du and make a simple table report output in \drg instead. I'm good with \drg as a new meta-command. > * Parenthetically, the "Attributes" column of \du is a complete > disaster > > I hadn't thought about this in detail but did get the same impression. David J. --0000000000004881f905fecdfed0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 22, 2023 at 5:08=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us>= wrote:
"Jonathan S. Katz" <jkatz@postgresql.org= > writes:
> On 6/15/23 2:47 PM, David G. Johnston wrote:
>> Robert - can you please comment on what you are willing to commit = in
>> order to close out your open item here.=C2=A0 My take is that the = design for
>> this, the tabular form a couple of emails ago (copied here), is >> ready-to-commit, just needing the actual (trivial) code changes to= be
>> made to accomplish it.

> Can we resolve this before Beta 2?[1] The RMT originally advised to tr= y
> to resolve before Beta 1[2], and this seems to be lingering.

At this point I kinda doubt that we can get this done before beta2
either, but I'll put in my two cents anyway:

* I agree that the "tabular" format looks nicer and has fewer i18= n
issues than the other proposals.

As you = are on board with a separate command please clarify whether you mean the ta= bular format but still with newlines, one row per grantee, or the table wit= h one row per grantor-grantee pair.

I still like using= newlines here even in the separate meta-command.

* Personally I could do without the "empty" business, but that se= ems
unnecessary in the tabular format; an empty column will serve fine.

I disagree, but not strongly.

<= /div>
I kinda expected you to be on the side of "why are we discussi= ng a situation that should just be prohibited" though.


* I also agree with Pavel's comment that we'd be better off taking<= br> this out of \du altogether and inventing a separate \d command.
Maybe "\drg" for "display role grants"?

Just to be clear, the open item fix proposal is to = remove the presently broken (due to it showing duplicates without any conte= xt) "member of" array in \du and make a simple table report outpu= t in \drg instead.

I'm good with \drg as a new met= a-command.


* Parenthetically, the "Attributes" column of \du is a complete disaster


I hadn't thought about t= his in detail but did get the same impression.

David J= .

--0000000000004881f905fecdfed0--