> On 21 Nov 2021, at 03:05, Todd Hubers <todd.hubers@gmail.com> wrote:
> 10) Tom said: "How would this interact with the "on login" triggers that people keep asking for?
>
> That's a good point. I would imagine that SET ROLE (which is currently unsuitable) would have the same requirement.
Theanswer is Shared Functions. SET ROLE calls a function like "SetSessionUserId". Our implementation should call the
samefunction(s). If OnLogin functionality is implemented they should trigger from there.
I think thats conflating session_user and current_user, SET ROLE is not a login
event. This is by design and discussed in the documentation:
"SET ROLE does not process session variables as specified by the role's
ALTER ROLE settings; this only happens during login."
The current patch proposal doesn't fire the login event trigger on SET ROLE,
only on actual logins. That patch needs more review before landing, but I'm
not sure tying it to SET ROLE is a good idea.
> 13. Tom said: "I wonder how we test such a feature meaningfully without incorporating a pooler right into the
Postgrestree."
>
> We can benchmark without a pooler - see the Benchmark section for details. (Furthermore, I propose that general
benchmarktooling does belong in Postgres for the benefit of the ecosystem of connection poolers. I have included such a
remarkin the Benchmarking section "PostgreSQL is not planning to incorporate Connection Pooling...".)
We might be talking about the same things using different words, but it's
important to remember that we need to cover the functionality in terms of
*tests* first, performance benchmarking is another concern.
--
Daniel Gustafsson https://vmware.com/