Thanks for the review!

I like the options but having thoughts on the interface for setting the interval. Currently we re-implement parsing seconds supporting syntax like 5 seconds and suggesting to users that this is an interval. I think that is a nice idea to leverage how intervals work and peoples familiarity with it but taking it a step further could be better and actually simplify how it works and reduce cases where people get surprised (ie. '3s' and '3 sec' are both valid intervals). In PG you can overload functions, so add cron.schedule taking text (cron definition) and cron.schedule taking actual interval.

postgres=# \df
                       List of functions
 Schema | Name | Result data type | Argument data types | Type
--------+------+------------------+---------------------+------
 public | test | void             | p_schedule interval | func
 public | test | void             | p_schedule text     | func
(2 rows)
postgres=# select test('* * * *');
NOTICE:  Text with * * * *
 test
------
(1 row)
postgres=# select test('1 s'::interval);
NOTICE:  Interval with 00:00:01
 test
------
(1 row)

This way users can have the parsing be done by PostgreSQL, and you can simply discard out of range intervals.

Alternatively you could take it further and try to support casting INTERVAL to a cron schedule where possible. This way you could allow using the interval syntax to define jobs that happen every N days, hours, minutes and convert that to their cron counterparts.

So that '2 hours'::interval could become 0 */2 * * *. The only problem is that cron has no representation for something running in second intervals so it doesn't have a nice mapping.

I think this change broke some valid cron syntax, such as 9,19,29,39,49,59 * * * *. This is now being interpreted as running every 9 seconds.

Hmz, that's bad. I'll look into it