There's been a lot of thrashing about whether LISTEN/NOTIFY should
restrict payload strings to 7-bit ASCII to avoid possible encoding
conversion failures. I was on the side of "yes" but I'm having
second thoughts about it. The point I had failed to think about
is that we already restrict notifies to only be received by backends
in the same database as the sending backend. (This is an inherent
implementation restriction in the pg_listener-based implementation,
and is kept for compatibility in the new code.) This means that
sender and receiver must have the same server_encoding, and so no
conversion issue can arise as far as the two backends are concerned.
Now it's true that we could get an encoding conversion failure while
trying to send the payload *to the client*, but it's not apparent
to me why we should restrict the feature because of that. There are
plenty of other reasons why we might fail to send the notification
to the client. Most obviously, we could also get an encoding
conversion failure on the notify condition name --- but we've never
enforced a character set restriction on that, and nobody's ever
complained about it AFAIR.
So the currently submitted patch is logically inconsistent. If we
enforce a character set restriction on the payload for fear of
being unable to convert it to the destination client_encoding, then
we should logically do the same for the condition name. But then
why not also restrict a lot of other things to pure ASCII?
I'm now thinking that we should just drop that restriction.
regards, tom lane
