Joe Conway <m...@joeconway.com> writes:
> Compared to both of these alternatives, I still feel that the specific
> SET ROLE hook is cleanest and best path forward. If there are no other
> comments or concerns, I will commit this in a day or two.
While I don't think there's any great harm in inventing such a hook, I'm
not sure it's going to be all that useful where placed. GUC assign_hooks
basically cannot risk throwing errors, which enormously restricts what can
safely be done inside the proposed hook: it would be unwise to do catalog
accesses, for example. (Which means I think the example usage is broken;
in fact, it's already broken by your note that the code has to be able to
execute in a failed transaction.)
I think a design that was actually somewhat robust would require two
hooks, one at check_role and one at assign_role, wherein the first one
would do any potentially-failing work and package all required info into
a blob that could be passed through to the assign hook.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
