Andrew Sullivan wrote:
> On Tue, Mar 30, 2004 at 12:16:50PM -0500, Steve Manes wrote:
>> I think he probably means like an Oracle job. Although cron works,
>> that would be handy so you wouldn't need to write wrapper scripts
>> just to run a proc.
>
> I hate to sound like an oldbie crank (although I'll admit to being a
> crank), but what exactly is the advantage supposed to be here? One
> invents a new special bit of database code which exists just so
> people don't have to write shell scripts? I guess the idea gets
> under my skin just because I have enough time-based problems without
> inventing a new interface to make it more complicated. Hmm. Looks
> like the sigmonster has gacked up a piece of wisdom.
>
> A
As one who was about to ask the same question, I can provide one reason:
ease of use/administration. I can create everything I need to
manage/process my database *in* my database, rather than in numerous
shell scripts scattered about. I had a weird issue with cron recently.
I needed to do some db maintenance and wanted to make sure no one was
going to change it, so I removed all cron jobs (crontab -r). Halfway
through, suddenly the database started getting updated!! I finally
figured out that my predecessors, for some reason, had stuck a couple
cron jobs in the root crontab, which I corrected. And of course, if I
copy a database someplace, the jobs would go with it; not so cron jobs.
Now having said this, I realize that even if a scheduler was added to
PostgreSQL, there is nothing to stop someone from additionally using
cron jobs anyway. But there would be less temptation to do so.
--
Guy Rouillier