On Mon, Feb 26, 2018 at 7:50 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Mon, Feb 26, 2018 at 4:55 PM, Paul Jungwirth <
> p...@illuminatedcomputing.com> wrote:
>
>> On 02/26/2018 03:47 PM, Tom Lane wrote:
>>
>>> PropAAS DBA writes:
>>>
We have a client which is segmenting
On Mon, Feb 26, 2018 at 4:55 PM, Paul Jungwirth wrote:
> On 02/26/2018 03:47 PM, Tom Lane wrote:
>
>> PropAAS DBA writes:
>>
>>> We have a client which is segmenting their multi-tenant cluster
>>> (PostgreSQL 9.6) by schema, however if one of their clients connects via
>>> pgadmin they see ALL s
On 02/26/2018 03:47 PM, Tom Lane wrote:
PropAAS DBA writes:
We have a client which is segmenting their multi-tenant cluster
(PostgreSQL 9.6) by schema, however if one of their clients connects via
pgadmin they see ALL schemas, even the ones they don't have access to
read.
PG generally doesn't
t from the system catalogs.
> What's the right/best practice approach? revoke all from public on
> specific system catalog tables? Which tables?
Messing with the system catalog permissions is likely to break stuff
you'd rather not break.
PG generally doesn't assume t
On 02/26/2018 03:11 PM, PropAAS DBA wrote:
All;
We have a client which is segmenting their multi-tenant cluster
(PostgreSQL 9.6) by schema, however if one of their clients connects
via pgadmin they see ALL schemas, even the ones they don't have access
to read. I assume pgadmin is pulling the
All;
We have a client which is segmenting their multi-tenant cluster
(PostgreSQL 9.6) by schema, however if one of their clients connects via
pgadmin they see ALL schemas, even the ones they don't have access to
read. I assume pgadmin is pulling the list from the system catalogs.
What's th
