--- Bruno Wolff III <__> wrote:
> On Thu, Dec 16, 2004 at 10:47:46 +0100,
> Csaba Nagy <nagy@ecircle-ag.com> wrote:
> > The only advantage would be that an in-database solution would be
> OS
> > independent and it could be managed using the same tools which
> manage
> > the database itself, including the backup and management of it. I'm
> not
> > sure how the Oracle thing is working, but I suppose you can manage
> it
> > using plain SQL. This makes for a more homogeneous solution.
> > Using cron makes your database solution OS dependent, and if you
> want to
> > programatically manage the tasks, then your program will be also OS
> > dependent.
> > This is about the advantages I can see of an integrated scheduling
> > service. That said, you can always shift that in your middle-tier
> (if
> > you have a 3 tier system), possibly backed by some DB tables (this
> is
> > how we do our scheduling here).
>
> cron isn't really part of the OS. Up until 8.0, any OS that Postgres
> ran on had cron. I have seen claims that there is a version of cron
> that
> runs under windows, but haven't verified that. Given this I don't see
> how a dependence on cron is going to cause you portability problems.
>
the cron you mention is www.wincron.com. I'm just started testing it...
seems a nice enough tool.
Here are my two cents on a sheduling engine:
I agree that a scheduling engine inside pgsql could be a useful tool,
and the advantage is that, even if cron may be available on all the
platforms pg runs, there are portability issues. The code cron runs may
(and it will probably will) have to be changed for each platform. On
the other side, having a sheduling engine inside postgresql would help
keeping the code I develop using postgres portable inside postgresql.
No matter on what platform I decide to setup postgresql, I know that
the triggers, functions and other stuff works.
regards,
R.
