On 2018/10/06 15:26, Michael Paquier wrote:
> On Fri, Oct 05, 2018 at 08:22:49AM -0400, Jesper Pedersen wrote:
>> Looks good.
>
> Actually, after sleeping on it, there could be potentially two problems:
> 1) We don't check the relkind of the relation. For example it is
> possible to get a tree from an index, which is incorrect. I would
> suggest to restrain the root relation to be either a relation, a
> partitioned table or a foreign table.
Hmm, how would one find the size of a partitioned index tree if we don't
allow indexes to be passed?
> 2) What about the users who can have a look at a tree? Shouldn't we
> tighten that a bit more? I am sure it is not fine to allow any user to
> look at what a partition tree looks like, hence only the owner of the
> root should be able to look at its tree, no?
Maybe, we should apply same rules as are used when describing a table or
when getting its metadata via other means (pg_relation_size, etc.)?
Afaics, there are no checks performed in that case:
create table foo (a int primary key);
create user mt;
revoke all on foo from mt;
set session authorization mt;
\d foo
Table "public.foo"
Column │ Type │ Collation │ Nullable │ Default
────────┼─────────┼───────────┼──────────┼─────────
a │ integer │ │ not null │
Indexes:
"foo_pkey" PRIMARY KEY, btree (a)
select pg_relation_size('foo');
pg_relation_size
──────────────────
0
(1 row)
Should we do anything different in this case?
Thanks,
Amit
