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

From: Arnaud Betremieux <arnaud(dot)betremieux(at)keyconsulting(dot)fr>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Cyrille Chépélov <cyrille(dot)chepelov(at)keyconsulting(dot)fr>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Listen / Notify - what to do when the queue is full
Date: 2010-01-11 10:05:45
Message-ID: 4B4AF7F9.3040201@keyconsulting.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2010-01-11 10:18:47 Re: mailing list archiver chewing patches
Previous Message Magnus Hagander 2010-01-11 09:46:10 Re: mailing list archiver chewing patches