Jeff Davis <pgsql@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.
> If the client successfully executed the LISTEN, then it could convert
> all of the characters in one direction.
You're assuming that the LISTEN was transmitted across the connection,
and not for example executed by a pre-existing function.
> The case of a condition name conversion error seems less problematic to
> me anyway, because it would happen every time; so there's no danger of
> making it through testing and then failing in production.
mmm ... that's assuming that condition names are constants, which isn't
necessarily the case either (I seem to recall generating condition names
even back in 1997).
> Ok. I'd feel a little better if I understood what would actually happen
> in the case of an error with NOTIFY. When does the client receive the
> error? Might the client code confuse it with an error for something
> synchronous, like a command execution?
Yeah, that's possible, but avoiding encoding conversion failures doesn't
eliminate that little hole in the protocol :-(. There are other ways
for the send attempt to fail. Admittedly, many of them involve a
connection drop, but not all.
In practice, since encoding conversion failures could interfere with the
results of almost any operation, it's not apparent to me why we should
single out NOTIFY as being so fragile it has to have an ASCII-only
restriction.
regards, tom lane
