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@xxxxxxxxxxxxxxxx, http://ScienceTools.com/
