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?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
