Very Computer

1. listen/notify argument (old topic revisited)

A while ago, I started a small discussion about passing arguments to a NOTIFY
so that the listening backend could get more information about the event.

There wasn't exactly a consensus from what I understand, but the last thing I
remember is that someone intended to speed up the notification process by
storing the events in shared memory segments (IIRC this was Tom's idea). That
would create a remote possibility of a spurious notification, but the idea is
that the listening application can check the status and determine what
happened.

I looked at the TODO, but I couldn't find anything, nor could I find anything
in the docs.

Is someone still interested in implementing this feature? Are there still
people who disagree with the above implementation strategy?

Regards,
        Jeff

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

2. PostgreSQL Date/Time Function Question

3. LISTEN/NOTIFY benchmarks?

4. How to retrieve new GUID on row insert with ADO/RecordSet?

5. Full Text

6. Synchronous LISTEN/NOTIFY?

7. Death of U.S. IT Industry: Neo-Nazi Fascist Scum Sell Out Native Sons

8. listen/notify argument (old topic revisited)

9. LISTEN/NOTIFY

10. DBD::Pg and NOTIFY (was Re: [GENERAL] Synchronous LISTEN/NOTIFY?)

11. problem with notify/listen

12. NOTIFY/LISTEN Using Embedded SQL (ecpg)