Well, if you program in Java for example, it is a portability problem to
call any native programs. It doesn't matter at all that the program
itself is portable, it is just not portable enough to call it at all,
not to mention other robustness problems arising from the Java-native
interaction.
Completely portable is nothing, but a solution which only requires you
to call your data base library with plain SQL is a lot more portable (in
any language you might use) than calling external programs.
Cheers,
Csaba.
On Thu, 2004-12-16 at 14:53, 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.