Re: Listen / Notify - what to do when the queue is full

A use case : use NOTIFY in a rule to send the primary key of a row that 
has been updated (for instance to manage a cache).

This requires a patch on top of this one, and it really is a separate 
concern, but I thought I'd give the use case anyway, since I believe it 
is relevant to the issues here.

I can see four kinds of NOTIFY statements :

1) The existing case    : NOTIFY channel
2) With Joachim's patch : NOTIFY channel 'payload'
3) My use case          : NOTIFY channel 'pay'||'load' (actually NOTIFY 
channel '<table_name>#'||OLD.id)
4) Taken one step further : NOTIFY channel (SELECT payload FROM payloads 
WHERE ...)

I'm working on a proof of concept patch to use Joachim's new notify 
function to introduce case 3. I think this means going through the 
planner and executor, so I might as well do case 4 as well. A use case I 
can see for case 4 is sending information in a rule or trigger about an 
updated object, when that information is stored in a separate table 
(versioning or audit information for example).

Cases 1 and 2 could remain utility commands, while cases 3 and 4 could 
go through the planner and the executor, the notify plan node calling 
Joachim's new notify function on execution.

Best regards,
Arnaud Betremieux

On 11/01/2010 07:58, Peter Eisentraut wrote:
> On mån, 2010-01-11 at 04:05 +0000, Greg Sabino Mullane wrote:
>    
>> On the one hand, I don't see the problem with ASCII here - the
>> payload is meant as a quick shorthand convenience, not a literal payload
>> of important information.
>>      
> Is it not?  The notify name itself is already a quick shorthand
> convenience.  Who knows what the payload is actually meant for.  Have
> use cases been presented and analyzed?
>
>
>
>