Arnaud Betremieux wrote:
> 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 know I'd be looking to send utf8 and byteas. Can notify as it stands today
take an expression for the payload (#4)?
The other issue is that libpq expects a string, so if non-c-string safe data is
to be sent a protocol change is needed or the server must hex encode all
payloads before transit and libpq must decode it; also requiring an
'payload_len' member be added to PGnotify. The latter is better IMHO as
protocol changes are nasty. Although, only needed to support bytea. If all we
want is utf8, then there is no issue with libpq.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
