> On Apr 13, 2019, at 17:28, Schneider, Jeremy <schnj...@amazon.com> wrote: > >> On Apr 11, 2019, at 19:52, Tom Lane <t...@sss.pgh.pa.us> wrote: >> >> Ron <ronljohnso...@gmail.com> writes: >>> I bet requests like this will start to make it onto the beaten path. >> >> Meh. I'm not that excited about inventing our own versions of wheels >> that already exist, especially when there's nothing very Postgres-specific >> about the requirements. Notice that the example I pointed you at is for >> sshd not Postgres. IMO the fact that you can use the same tool to solve >> both cases is a good thing. > > This might work for sending an email, but not very useful if I want to do > something in the database. > > For example, one very common use of logon triggers in other databases is to > look at various connection parameters (like username or source IP) and enable > sql logging or debugging for only certain cases (not always doing the same > thing for a particular user). Another common use case is to do something like > running plpgsql or manipulating data in db tables - but again looking at some > combination of things at a database level to make a decision about what to > do; for example the application itself might enable or disable certain > behaviors by setting values in a configuration table.
Probably worth mentioning that I’m all for solving this in the application - just that I’ve experienced many cases in the past where it wasn’t feasible or even possible to get the sorts of changes I’d need into applications using the databases that I was responsible for. > I’m still trying to work out the best approach for solving these sorts of use > cases in current versions of PostgreSQL... I’m curious how others are solving > this?
