On Fri, Jun 10, 2022 at 6:17 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
> On Fri, 2022-06-10 at 17:17 +0900, Etsuro Fujita wrote:
> > > I am not sure if it worth adding to the documentation. I would never have thought
> > > of the problem if Phil hadn't brought it up. On the other hand, I was surprised
> > > to learn that permissions aren't checked until the executor kicks in.
> > > It makes sense, but some documentation might help others in that situation.
> >
> > +1 for adding such a document.
> >
> > > I'll gladly leave the decision to your judgement as a committer.
> >
> > IIRC, there are no reports about this from the postgres_fdw users, so
> > my inclination would be to leave the documentation alone, for now.
>
> I understand that you are for documenting the timing of permission checks,
> but not in the postgres_fdw documentation.
Yes, I think so.
> However, this is the only occasion
> where the user might notice unexpected behavior on account of the timing of
> permission checks. Other than that, I consider this below the threshold for
> user-facing documentation.
I think PREPARE/EXECUTE have a similar issue:
postgres=# create table t1 (a int, b int);
CREATE TABLE
postgres=# create user foouser;
CREATE ROLE
postgres=# set role foouser;
SET
postgres=> prepare fooplan (int, int) as insert into t1 values ($1, $2);
PREPARE
postgres=> execute fooplan (9999, 9999);
ERROR: permission denied for table t1
The user foouser is allowed to PREPARE the insert statement, without
the insert privilege on the table t1, as the permission check is
delayed until EXECUTE.
So I thought it would be good to add a note about the timing to the
documentation about the Postgres core, such as arch-dev.sgml (the
"Overview of PostgreSQL Internals" chapter). But as far as I know,
there aren’t any reports on the PREPARE/EXECUTE behavior, either, so
there might be less need to do so, I think.
Thanks for the discussion!
Sorry for the delay.
Best regards,
Etsuro Fujita