Re: Trigger to run @ connection time?

From: Berend Tober <btober(at)ct(dot)metrocast(dot)net>
To: Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kynn Jones <kynnjo(at)gmail(dot)com>, pgsql-general General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Trigger to run @ connection time?
Date: 2008-03-13 01:00:17
Message-ID: 47D87CA1.2050309@ct.metrocast.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Alban Hertroys wrote:
> On Mar 11, 2008, at 10:28 PM, Tom Lane wrote:
>
>> An ON CONNECT trigger enforced by the database seems a bit scary to me.
>> If it's broken, how you gonna get into the DB to fix it?
>>
>> regards, tom lane
>
> If creating the trigger wouldn't be possible from within the database
> that it's defined for (which would be strange anyway as far as I'm
> concerned, since you are already connected at that point and thus missed
> an opportunity to fire that trigger) this shouldn't be a problem.
>
> To put that into an SQL statement, something like:
> #template1 $ CREATE TRIGGER my_database_connect_trg BEFORE CONNECT ON
> my_database EXECUTE PROCEDURE my_database_setup()
>
> Although of course that begs the question where that procedure would be
> stored; Rather not in template1, I suppose! This points to another
> problem with ON CONNECT triggers, you'll likely need to be connected to
> reach the stored procedure that the trigger calls! A nice chicken and
> egg problem, with some scope issues on the horizon...

I envision this not so much as a BEFORE connect trigger, but
rather as an event that happens after the point of the user being
successfully authenticated, but before executing any user
application commands -- in fact before even starting to listen
for any incoming application commands.

A particular implementation I see this useful for, to give some
context to thinking about this, is to update a user password
expiration date (to, say, CURRENT_DATE + 30) at each login. This
would then allow the creation of a system that lets unused
accounts expire but automatically maintains the validity of
actively used accounts, for example. I can think of other uses, too.

I currently achieve this functionality with an event triggered in
an end-user application, but I'd really like it to happen in the
data base so that every application that access this data base
doesn't have to recreate that particular functionality -- and
also so as to eliminate to problem of the functionality not being
implemented by other applications outside our control that access
the data base.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ow Mun Heng 2008-03-13 01:53:25 Column Statistics - How to dertermine for whole database
Previous Message Alban Hertroys 2008-03-12 23:06:07 Re: Trigger to run @ connection time?