Re: Does PostgreSQL support job?
От | Daniel Caune |
---|---|
Тема | Re: Does PostgreSQL support job? |
Дата | |
Msg-id | 1E293D3FF63A3740B10AD5AAD88535D201755BE2@UBIMAIL1.ubisoft.org обсуждение исходный текст |
Ответ на | Does PostgreSQL support job? ("Daniel Caune" <daniel.caune@ubisoft.com>) |
Список | pgsql-sql |
> Daniel Caune wrote: > >>> I'm not sure to understand. Why calling a function from a script is > >>> different from executing a series of SQL commands? > > [snip] > >>>Does that make sense? > >>It does make sense if myjob() does more than just execute a bunch of > >>statements, e. G. it contains if(), loops or something else. > >>PLPGSQL is turing complete, plain SQL is not. > > Yes, indeed, that was the idea! > > There's another reason: For updating the cron job SQL commands, you need > root access (or at least shell access) to the database machine. For > updating a stored procedure, you need just the appropriate rights in the > database. > > On larger deployments, this can be an important difference. > You are absolutely right. That is such detail I was thinking over. Managing stored procedures into a RDBMS seems less laborious than modifying some SQL scripts on the file system. I mean there is always a need to define initially a script, run by the cron/psql couple, which calls a stored procedure responsible for doing the job ("SELECT myjob();"). Therefore it is easier to modify implementation details of the job without having to modify the script run by the cron/psql. On another hand, it seems easier to test modification by patching a stored procedure directly in the RDBMS and making some tests on-the-fly. -- Daniel CAUNE
В списке pgsql-sql по дате отправления: