On Mon, Mar 5, 2012 at 4:44 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
>
> Excerpts from Artur Litwinowicz's message of lun mar 05 18:32:44 -0300 2012:
>
>> Ouch... "in next 2-4 years" - it broke my heart like a bullet - You
>> should not write it... ;)
>> I feel that I need to set aside SQL, Python, PHP and so on and take to
>> my hands old book about C programming language from university ;)
>> I hope my words are like drops of water for this idea and in the future
>> some people will be happy to use professional job manager :)
>
> Keep in mind that it's not about coding in C but mostly about figuring
> out what a sane design out to look like.
Just so.
And it seems to me that the Right Thing here is to go down the road to
having the fabled Stored Procedure Language, which is *not* pl/pgsql,
in that iIt needs to run *outside* transactional context. It needs to
be able to start transactions, not to run inside them.
Given a language which can do some setup of transactions and then run
them, this could be readily used for a number of useful purposes, of
which a job scheduler would be just a single example.
It would enable turning some backend processes from hand-coded C into
possibly more dynamically-flexible scripted structures.
I'd expect this to be useful for having more customizable/dynamic
policies for the autovacuum process, for instance.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"