See my comments below.
On Thu, 2004-12-16 at 21:01, Greg Stark wrote:
> Csaba Nagy <nagy@ecircle-ag.com> writes:
>
> > The only advantage would be that an in-database solution would be OS
> > independent
>
> That kind of argument leads to monstrosities like Oracle that reimplement
> everything they can from the OS.
>
Now, cron isn't exactly part of the OS, is it ?
I wouldn't care if the postgres implementation would use cron
internally, as long as I can control it through plain SQL. The argument
was that the data base could hide the OS, not that it should not use it,
nor reimplement it.
> What would be a neat project is if someone wrote a cron implementation that
> used postgres as a backend. You could run cron from the command-line and edit
> your cron jobs normally, but the resulting data would get stuffed into a
> postgres database. The cron daemon would connect to the database to get its
> information.
>
This actually is a very nice idea. It has the distinct advantage that it
doesn't have to be limited to Postgres, it could connect to any data
base, or any other data store providing the needed functionality.
> This would be neat since it would let applications access and modify the data
> through a well defined programmatic interface, but the data could easily be
> queried using SQL to display in a nice GUI or HTTP interface.
>
> I suspect this would be very attractive to shared hosting systems. It would
> also be convenient for applications that want to provide more restricted
> access to application-specific routine jobs.
>
> This wouldn't really be a part of Postgres though, just another application
> using Postgres. It could be something Postgres could recommend for people who
> find cron too awkward for their application.