Re: Does PostgreSQL support job?

From: "Daniel Caune" <daniel(dot)caune(at)ubisoft(dot)com>
To: "Markus Schaber" <schabi(at)logix-tt(dot)com>
Cc: "Owen Jacobson" <ojacobson(at)osl(dot)com>, <pgsql-sql(at)postgresql(dot)org>
Subject: Re: Does PostgreSQL support job?
Date: 2006-02-02 15:21:24
Message-ID: 1E293D3FF63A3740B10AD5AAD88535D201755BE2@UBIMAIL1.ubisoft.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Browse pgsql-sql by date

  From Date Subject
Next Message Markus Schaber 2006-02-02 15:38:54 Re: Does PostgreSQL support job?
Previous Message Markus Schaber 2006-02-02 14:25:32 Re: Does PostgreSQL support job?