On Sat, Feb 22, 2003 at 11:14:47AM -0500, Tom Lane wrote:
>
> Hmm. Once you have started to type, it would be annoying for the
> thing to spit out notifications, even if you momentarily backspace
> out what you've typed. I'd argue that it's only okay to print
> notifications after completion of a command (where at least some
> backslash constructs, eg \r, could be allowed to count as a command).
I'm not saying it should be mandatory, but how about receiving
notifications whenever a blank line is entered, or any time as long
as the current input line is empty? Perhaps the input line could be
redisplayed after the notification message, similar to how most shells
handle commands being typed while another command is still executing.
Even if an unexpected notification is a little annoying during an
interactive session, how often does it happen? Would it be a problem
to have a variable to define how often pending notifications should be
checked for?
> I find it kind of hard to envision situations where you'd really care
> anyway. No one's going to use psql as the base for an interactive
> application that depends on LISTEN/NOTIFY, surely?
Surely not. I'm thinking more of developers, including first-time
postgres users, who use psql to experiment with new queries, new
schemas, SQL and postgres features they're not familiar with, and so on.
Many of them come back to ask why their notifications aren't arriving.
So I thought it would be more insightful to them if notifications could
be printed straightaway.
Imagine you're maintaing a program that sends out notifications, and
you want to get a feel for when this happens. I think it would be
nice to be able to open a shell, run psql, issue a LISTEN and just
let it sit there and print out anything that comes along, while you
play with the application in another window.
Jeroen
