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.
The only real advantage I see are for those people in hosting environments that don't really have access to cron. I suppose it's also valuable in making your scripts more portable as you wouldn't need to make further alterations to the system beyond restoring a database backup or whatnot.
In all, I think PostgreSQL has bigger fish to fry.
I tend to agree with this. As familiar as probably most of us with cron, it is: a) an external tool (which means in some environment people don't get access to it); b) Unix-only (yes, there are ports or clones on Win32 etc, but still the whole thing is Unix-oriented, like one crontab per *Unix user* instead of database user, using SHELL=... etc); c) reporting/status is by e-mail only.
In short, it would be nice if we have a scheduling system where one can run queries or in-process procedures/functions instead of external commands. Also where one can use normal SQL/psql commands to manipulate the jobs; cron entries aren't exactly "programmable" or "structured" (e.g. how do you easily find entries that runs at least once every 10 min or more often?)
-- dave
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
