Joe Conway <m...@joeconway.com> writes:
> In reference to:
> http://archives.postgresql.org/message-id/6534f7ae0811181547v1dc1f096g6222e8273b461...@mail.gmail.com
> Had to fix a lot of bit rot, but otherwise looks good. My updated patch
> attached. Will commit in a day or so if no objections.
After a quick look-over, here are some comments on the patch itself:
1. Sooner or later, hopefully sooner, we will have "payload" strings in
notifications, not just the "relname" string. libpq and the protocol
already have support for that (see the "extra" field in PGnotify).
It would be a shame to have this function's API become obsolete
immediately. Can we fix the API to return the "extra" string too?
2. By the same line of reasoning, the be_pid field might be useful.
Back when I was doing a lot of LISTEN/NOTIY coding, you really needed
that field in order to distinguish your own notifies coming back from
other sessions' notifies. I don't think we've done anything to
eliminate the need for that.
3. I see the function returns NULL when there's nothing to report,
but maybe an empty array would be more sensible.
[ thinks for awhile... ] Actually, it seems to me that the present
patch's definition of the function would be very hard to work with.
You would normally want to work with the events one at a time.
There isn't much you could do with the array result except unnest() it,
and I'm a bit worried that careless usage could result in multiple
evaluation of the function and hence loss of events. I wonder whether
it would be better to have the function return setof record. Which, not
incidentally, would greatly simplify adding in those extra result
fields.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
