[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@gmail.com> writes:
> > On Mon, Aug 28, 2017 at 1:28 PM, Jerry Regan <
> > jerry.regan@concertoglobalresources.com> 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
--
