Re: Discussion on a LISTEN-ALL syntax

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.

In response to

Responses

Browse pgsql-hackers by date

  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