On Fri, 2002-03-22 at 06:40, Tom Lane wrote:
> 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 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
