On Sun, 2010-02-14 at 15:15 -0500, Tom Lane wrote:
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.
If the client successfully executed
Jeff Davis pg...@j-davis.com writes:
On Sun, 2010-02-14 at 15:15 -0500, Tom Lane wrote:
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.
On Sun, Feb 14, 2010 at 03:15:30PM -0500, Tom Lane wrote:
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
On Mon, 2010-02-15 at 13:53 -0500, Tom Lane wrote:
You're assuming that the LISTEN was transmitted across the connection,
and not for example executed by a pre-existing function.
Ok, good point.
In practice, since encoding conversion failures could interfere with the
results of almost any
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
