[EMAIL PROTECTED] (Marco Colombo) writes: > On Thu, 16 Dec 2004, Christopher Browne wrote: >> None of this means forcing it into the database implementation; it >> just means that it would be useful. "pgcron" sounds like an >> utterly splendid idea. > > Is the Oracle one _just_ that? A cron/at replacement? What about > porting every UNIX utility to the DB engine (that would be a > cross-platfrom Unix - wow)? Why don't they put web and application > server functionality (apache and PHP) in the DB? No, wait... ehm... > :-) > > Seriously, such an application (scheduler) _will_ have to deal with > OS differences. Interesting things to log about the spawned jobs > will be different. They way you run then (I don't mean the actual > system call, think of nice level instead) may be different.
That's well and nice; if I had a "database-driven" cron alternative, I would use it, possibly on several platforms, as it would provide compelling advantages over traditional cron. I think it would provide compelling advantages to my employer, too. I'm _not_ asking for some "Barneyfied All Encompassing Interface;" I'm _not_ asking for it to be treated as an integral part of PostgreSQL. You're picking a strawman argument there, and trying to suggest that's what I'm looking for. I'm certainly NOT. I don't want Oracle, but I could use a better cron, and anacron isn't the answer. We have some challenges concerning generating reports; I consider that having a "better scheduler" than cron is one of the pieces of that particular puzzle. > I wonder if limiting the application domain to DB-related jobs only > would help. I mean, it is quite common to run time based procedures > at DB level, like report generation or table summarization. Usually, > this activities are driven by _external_ schedulers (cron), via > scripts that need to connect and _authenticate_, which leads to > security nightmares. No, the sorts of things that "pgcron" enables are most certainly _NOT_ reasonably limited to just "DB-related" jobs. Having an interface providing access to history information about past jobs enables plenty of things that don't require that the application cares about databases at all. -- "cbbrowne","@","ca.afilias.info" <http://dev6.int.libertyrms.com/> Christopher Browne (416) 673-4124 (land) ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
