Re: SQL Property Graph Queries (SQL/PGQ)
| От | Ashutosh Bapat |
|---|---|
| Тема | Re: SQL Property Graph Queries (SQL/PGQ) |
| Дата | |
| Msg-id | CAExHW5vgWTK3rTE1Twr3qp6EmMPz6BgxUKs1Ou-f3nE9Smn62w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: SQL Property Graph Queries (SQL/PGQ) (Amit Langote <amitlangote09@gmail.com>) |
| Список | pgsql-hackers |
On Mon, Dec 8, 2025 at 5:56 PM Amit Langote <amitlangote09@gmail.com> wrote: > > On Thu, Dec 4, 2025 at 2:23 AM Ashutosh Bapat > > In your commit message: > > 4. We have not implemented security definer property graphs since > SQL/PGQ standard does not mention those. > > My reading of the access rules is that, from the caller’s point of > view, the standard expects behavior that is quite close to > security-definer semantics -- once the session user has SELECT on the > property graph, they do not need privileges on the element tables. Is > that also how you read it, or do you see the standard as intentionally > leaving room for invoker semantics like you've currently implemented? > The standard specifies that in order to reference a property graph in the query, the query invoker has to have SELECT privileges on the property graph. I am not able to find a specification which answers: who's privileges should be used to access the underlying tables. So I can't say whether it's close to security-definer semantics or not. I also can not infer any intent. But as I have explained above, security-definer semantics seem to be too dangerous to implement. But may be there's some other safe interpretation of standard specification, which I am missing. -- Best Wishes, Ashutosh Bapat
В списке pgsql-hackers по дате отправления: