On Tue, Feb 3, 2009 at 8:58 PM, Guy Rouillier <guyr-...@burntmail.com> wrote: > Greg Stark wrote: >> >> My only point was that this would be very different from Oracle-style >> job scheduler implemented *inside* the database using >> database-specific code and requiring database-specific code to >> interact with the outside world. That's just reimplementing the whole >> world using the database as a weird operating system which is someone >> else's game. > > And someone else might want to play that game inside PG ;). Seriously, we > already have programs running inside the DB (stored procs), so why not jobs? > I can think of several useful applications. I have an application with a > high volume of inserts (60M + per day). Maybe I can conceive of some way to > reorganize the previous day's data at 2 am each morning that will provide > much better performance. Since all that activity is inside the database, > why not schedule it inside the DB also? It's the same logic to justify > stored procs.
Yep, this allows enough separation from OS and db that I can give users permission to schedule jobs in the db without needing to have an account on my db server or a cronjob connection remotely and anonymously from who knows what machine. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
