> On Apr 13, 2019, at 17:28, Schneider, Jeremy <schnjere@amazon.com> wrote:
>
>> On Apr 11, 2019, at 19:52, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> Ron <ronljohnsonjr@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
(likeusername or source IP) and enable sql logging or debugging for only certain cases (not always doing the same thing
fora 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
examplethe 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
thepast where it wasn’t feasible or even possible to get the sorts of changes I’d need into applications using the
databasesthat 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?
