[HACKERS] LISTEN/NOTIFY versus encoding conversion
in [PgSql]
|
Prev: PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl
Next: [COMMITTERS] pgsql: Add psql tab completion for DO blocks.
From: Tom Lane on 14 Feb 2010 15:15 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |