From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Trey Boudreau <trey(at)treysoft(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Discussion on a LISTEN-ALL syntax |
Date: | 2024-12-20 22:23:31 |
Message-ID: | CAKFQuwYxSOELA-MT_TNbDgPbs5Q+wE+EM0_tBDWOmHDY+Gkpvg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Friday, December 20, 2024, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Trey Boudreau <trey(at)treysoft(dot)com> writes:
>
> * "Listen to all but X" seems like a reasonable desire.
>
This I concur with, and would add: let me name my channels
accounting.payables, accounting.receivables, sales.leads; and let me listen
or ignore all accounting/sales channel names.
But staying within the existing “deny default, permissive grants only”
design to meet this specific goal seems like a reasonable incremental step
to accept. Let others wanting to work on a more expansive capability
change brings those patches forth.
As for exposing this to the user, this allow-all “channel” would be
presented as any other normal channel. The reader would need to know about
the special meaning of whatever label we end up using. IOW, the wildcard is
the label and no attempt to tie real in-use channel names to it should or
even could be attempted.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias van de Meent | 2024-12-20 22:41:16 | Bug: mdunlinkfiletag unlinks mainfork seg.0 instead of indicated fork+segment |
Previous Message | Daniel Gustafsson | 2024-12-20 22:20:58 | Re: [PoC] Federated Authn/z with OAUTHBEARER |