Neil Conway <nconway@klamath.dyndns.org> writes:
>> BTW, I would like to see a spec for this "notify with parameter" feature
>> before it's implemented, not after.
> The current syntax I'm using is:
> NOTIFY condition_name [ [WITH MESSAGE] 'my message' ];
Hm. How are you going to transmit that to the client side without
changing the FE/BE protocol? (While we will no doubt find reasons
to change the protocol in the future, I'm not eager to force a protocol
update right now; at least not without more reason than just NOTIFY
parameters.) If we want to avoid a protocol break then it seems
like the value transmitted to the client has to be a single string.
I guess we could say that what's transmitted is a single string in
the formcondition_name.additional_text
(or pick some other delimiter instead of dot, but doesn't seem like
it matters much). Pretty grotty though.
Another thought that comes to mind is that we could reinterpret the
parameter of LISTEN as a pattern to match against the strings generated
by NOTIFY --- then there's no need to draw a hard-and-fast distinction
between condition name and parameter text; it's all in the eye of the
beholder. However it's tough to see how to do this without breaking
backwards compatibility at the syntax level --- you'd really want LISTEN
to be accepting a string literal, rather than a name, to make this
happen.
That brings up the more general point that you'd want at least
the "message" part of NOTIFY to be computable as an SQL expression,
not just a literal. It might be entertaining to try to reimplement
NOTIFY as something that's internally like a SELECT, just with a
funny data destination. I find this attractive because if it were
a SELECT then it could have (at least on the inside) a WHERE clause,
which'd make it possible to handle NOTIFYs in conditional rules in
a less broken fashion than we do now.
regards, tom lane
