[I meant to send this to the list] On Mon, Aug 28, 2017 at 07:08:28PM -0400, Tom Lane wrote: > "David G. Johnston" <david.g.johnston@xxxxxxxxx> writes: > > On Mon, Aug 28, 2017 at 1:28 PM, Jerry Regan < > > jerry.regan@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > >> My concern is how, after LISTENing in psql, I can tell it what to do when > >> the NOTItFY is received. > > > As far as I am aware you cannot. > > Yes, and psql is not designed to do anything of its own accord, > so I think the answer is really "use another program". > > > "Whenever a command is executed, psql also polls for asynchronous > > notification events generated by LISTEN and NOTIFY." > > Exactly. If you don't feed it a command, it just sits there. > > > I suspect the feature request would be something like: > > \set NOTIFY_PROGRAM './process-notify-request.bash' (or an equivalent > > meta-command) > > And psql would invoke said program and pass the content of the notification > > payload to it via stdin. > > Such a program could only execute after the next time you give a command > to psql. You could maybe imagine feeding it a continuous stream of dummy > commands, but that's pretty silly (and rather defeats the point of LISTEN, > which is to *not* eat cycles while waiting). What would it take to have pqasyncnotifier [0] adopted by PostgreSQL? pqasyncnotifier solves all the problems that psql has regarding LISTENing for notifications. Note too that pqasyncnotifier doesn't poll, rather, it blocks in PQconsumeInput(). [0] https://github.com/twosigma/postgresql-contrib/blob/master/pqasyncnotifier.c (Oy, I just noticed that the PQfinnish() call needs to move up to the end of the for (;;) loop...) Nico -- -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
