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
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? |