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
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
Jeff Davis 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.
> If the
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 execute
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
