On Fri, 2002-03-22 at 06:40, Tom Lane wrote: > Neil Conway <[EMAIL PROTECTED]> 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 form > condition_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.
That'ts what I suggested a few weeks ago in a well hidden message at the end of reply to somewhat related question ;) > 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. Can't we accept both - name for simple things and string for regexes. > 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. I think this should be any expression that returns text. I even wouldnt mind if I had to use explicit insert: insert into pg_notify select relname || '.' || cast(myobjectid as text), listenerpid from pg_listener where 'inv' ~ relname Just the delivery has to be automatic. > It might be entertaining to try to reimplement > NOTIFY as something that's internally like a SELECT, just with a > funny data destination. I thought that NOTIFY is implemented as an INSERT internally, no ? > 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. -------------- Hannu ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
