On Nov 2, 2006, at 15:00 , Richard Troy wrote:
>
>
> On Thu, 2 Nov 2006, AgentM wrote:
>>>
>>> Just some commentary... This is exactly the sort of thing cron is
>>> for. Duplicating that functionality in the RDBMS would be silly
>>> IMO. I don't see why you could consider cron to be "dirty" for
>>> this application...
>>
>> I actually tried to come up with something for this. There are plenty
>> of good reasons to have some timer functionality in the database:
>>
>> 1) it makes regular database-oriented tasks OS portable
>> 2) your cron user needs specific permissions + authorization to
>> access the database whereas postgres could handle "sudo"-like
>> behavior transparently
>> 3) there are triggers other than time that could be handy- on vacuum,
>> on db start, on db quit, on NOTIFY
>>
>> Unfortunately, the limitation I came across was for 2). There is no
>> way to use "set session authorization" or "set role" safely because
>> the wrapped code could always exit from the sandbox. So my timer only
>> works for db superusers.
>>
>> -M
>
> ...This type of need is exactly what custom written daemons are for.
> They're surely database and OS portable (or can be, at least),
> there's no
> need for any super-user capability of any kind, you can use any
> kind of
> trigger you like, and there's no permission leakage problem,
> either... I
> guess all you need is functioning nohup capability (which Windows
> systems
> may have trouble with, I don't know).
Sure- I wrote a custom daemon. But it has general usefulness. Instead
of ten clients listening on ten notifications (and holding open
connections for little reason), I would like to have one connection
handle all the notification events- based on which notification or
timer event, it could call a different stored procedure with
different roles. That way, I wouldn't need one connection open for
ever user that needs to listen and react. That simply doesn't scale.
Cheers,
M
