Re: [HACKERS] Provide list of subscriptions and publications inpsql's completion
От | Jim Nasby |
---|---|
Тема | Re: [HACKERS] Provide list of subscriptions and publications inpsql's completion |
Дата | |
Msg-id | 9ada39f5-7832-05f9-c146-4d53c2926284@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Provide list of subscriptions and publications inpsql's completion (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [HACKERS] Provide list of subscriptions and publications inpsql's completion
|
Список | pgsql-hackers |
On 2/13/17 9:36 PM, Michael Paquier wrote: >> 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. Why not do what we do for pg_stat_activity.current_query and leave it NULL for non-SU? Even better would be if we could simply strip out password info. Presumably we already know how to parse the contents, so I'd think that shouldn't be that difficult. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532)
В списке pgsql-hackers по дате отправления: