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
