From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Provide list of subscriptions and publications in psql's completion |
Date: | 2017-02-14 03:36:11 |
Message-ID: | CAB7nPqRaYXsJEQVNya+HrC=uYKa-QkaRxfxVz3GCC09Vr5XOtw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 14, 2017 at 2:07 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> No, the tab-completions for ALTER/DROP PUBLICATION should show the local
> publications because those commands drop and alter the local ones. OTOH,
> CREATE/ALTER SUBSCRIPTOIN ... PUBLICATION should show nothing because
> the remote publications in the publisher side should be specified there.
Doh, yes. You are right about that.
>> - Addition of a view pg_subscriptions with all the non-sensitive data.
>> (- Or really extend pg_stat_subscriptions with the database ID and use
>> it for tab completion?)
>
> Probably I failed to get Peter's point... Anyway IMO that we can expose all the
> columns except the sensitive information (i.e., subconninfo field)
> in pg_subscription to even non-superusers. Then we can use pg_subscription
> for the tab-completion for ALTER/DROP SUBSCRIPTION.
To be honest, I find subconninfo quite useful to check where a
subscription is getting its changes from, so I'd rather not touch it.
It looks as well a bit overkill to just create a new view on an object
type non-superusers cannot even use... There are already 1 view and 1
system catalog related to it, so I'd be of the opinion to let it fail
silently with a permission error and keep it as an empty list for
them.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-02-14 03:42:00 | pg_waldump's inclusion of backend headers is a mess |
Previous Message | Tom Lane | 2017-02-14 03:34:35 | Re: Possible TODO: allow arbitrary expressions in event trigger WHEN |