Mime-Version: 1.0 (Apple Message framework v752.2)
In-Reply-To: <Pine.LNX.4.33.0611021157280.1126-100000@denzel.in>
References: <Pine.LNX.4.33.0611021157280.1126-100000@denzel.in>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <8ABD7C06-79D9-44F6-B21B-7C4F8E0FCB3B@themactionfaction.com>
Content-Transfer-Encoding: 7bit
From: AgentM <agentm@themactionfaction.com>
Subject: Re: Is there anyway to...
Date: Thu, 2 Nov 2006 14:55:50 -0500
To: pgsql general <pgsql-general@postgresql.org>


On Nov 2, 2006, at 15:00 , Richard Troy wrote:

>
>
> On Thu, 2 Nov 2006, AgentM wrote:
>>>
>>> Just some commentary...  This is exactly the sort of thing cron is
>>> for.  Duplicating that functionality in the RDBMS would be silly
>>> IMO.  I don't see why you could consider cron to be "dirty" for
>>> this application...
>>
>> I actually tried to come up with something for this. There are plenty
>> of good reasons to have some timer functionality in the database:
>>
>> 1) it makes regular database-oriented tasks OS portable
>> 2) your cron user needs specific permissions + authorization to
>> access the database whereas postgres could handle "sudo"-like
>> behavior transparently
>> 3) there are triggers other than time that could be handy- on vacuum,
>> on db start, on db quit, on NOTIFY
>>
>> Unfortunately, the limitation I came across was for 2). There is no
>> way to use "set session authorization" or "set role" safely because
>> the wrapped code could always exit from the sandbox. So my timer only
>> works for db superusers.
>>
>> -M
>
> ...This type of need is exactly what custom written daemons are for.
> They're surely database and OS portable (or can be, at least),  
> there's no
> need for any super-user capability of any kind, you can use any  
> kind of
> trigger you like, and there's no permission leakage problem,  
> either... I
> guess all you need is functioning nohup capability (which Windows  
> systems
> may have trouble with, I don't know).

Sure- I wrote a custom daemon. But it has general usefulness. Instead  
of ten clients listening on ten notifications (and holding open  
connections for little reason), I would like to have one connection  
handle all the notification events- based on which notification or  
timer event, it could call a different stored procedure with  
different roles. That way, I wouldn't need one connection open for  
ever user that needs to listen and react. That simply doesn't scale.

Cheers,
M