|From:||Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>|
|To:||Michael Paquier <michael(at)paquier(dot)xyz>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>|
|Cc:||Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: partition tree inspection functions|
|Views:||Raw Message | Whole Thread | Download mbox|
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;
Column │ Type │ Collation │ Nullable │ Default
a │ integer │ │ not null │
"foo_pkey" PRIMARY KEY, btree (a)
Should we do anything different in this case?
|Next Message||'Christoph Moench-Tegeder'||2018-10-09 08:12:17||Re: Function for listing archive_status directory|
|Previous Message||Amit Langote||2018-10-09 08:00:51||Re: executor relation handling|