Gregory Wood 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.
>
> 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
