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).
Richard
--
Richard Troy, Chief Scientist
Science Tools Corporation
510-924-1363 or 202-747-1263
rtroy@ScienceTools.com, http://ScienceTools.com/
