<snip> > I suggest that what might be saner is to consider that the "objects" > that the hook calls are concerned with are the pg_setting_acl entries, > not the underlying GUCs, and thus that the hooks need be invoked only > when creating, destroying or altering those entries. If we do have > a need for a hook editorializing on GUC value settings, that would > have to be an independent API --- but I have heard no calls for > the ability to have such a hook, and I don't think that this patch > is the place to introduce one. I requested it here: https://www.postgresql.org/message-id/CAGB%2BVh5pVFAqw8YzeXy4xxmEt_4Hq_8pEUHdCQvv3mCjvC-S-w%40mail.gmail.com with compromises here: https://www.postgresql.org/message-id/CAGB%2BVh6wLJ3FKsno62fi54pfg0FDrZRWcpuuCJBkHcCj-G1ndw%40mail.gmail.com https://www.postgresql.org/message-id/0A3D3CBA-6548-4C9E-9F46-59D5C51A1F31%40enterprisedb.com https://www.postgresql.org/message-id/CAGB%2BVh65R5vKC4rEt7r2_pK3kMZd-VY0n99RJwcP8Bic7xvOxQ%40mail.gmail.com and the new version here: https://www.postgresql.org/message-id/C8DF19D8-C15D-4C2D-91CA-391390F1E421%40enterprisedb.com which I wrote. a toy module to test and was satisfied with it, despite the limitations. If we are adding a DAC Grant for a type of object it seems untenable that it would not come with analogous MAC capable hooks. Thank you.
pgsql-hackers by date:
Соглашаюсь с условиями обработки персональных данных
