"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).
This isn't something that could be easily fixed, AFAICS. Even if we
wanted to make psql pay attention to asynchronous data arrival, how
would we get control back from libreadline? And what would happen
if the user had typed a partial line of input?
You really are much better off creating a program that opens its own
connection to the DB and sits there listening. psql cannot help you
meaningfully with this request, and I can't see a way to make it do
so that wouldn't be a monstrous kluge.
regards, tom lane
