On Fri, Jun 10, 2022 at 6:17 PM Laurenz Albe <laurenz.a...@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
