Craig Ringer <ring...@ringerc.id.au> writes:
> On 09/17/2011 05:10 AM, Carlo Curatolo wrote:
>> Just tried with PG 9.1...same problem...
> Yep. There appears to be no interest in fixing this bug. All the
> alternatives I proposed were rejected, and there doesn't seem to be any
> concern about the issue.
The problem is to find a cure that's not worse than the disease.
I'm not exactly convinced that forcing all log messages into a common
encoding is a better behavior than allowing backends to log in their
native database encoding.
If you do want a common encoding, there's a very easy way to get it, ie,
standardize on one encoding for all your databases. People who aren't
doing that already probably have good reasons why they want to stay with
the encoding choices they've made; forcing their logs into some other
encoding isn't necessarily going to improve their lives.
> ... The only valid fixes are to log them to different files (with some
> way to identify which encoding is used)
I don't recall having heard any serious discussion of such a design, but
perhaps doing that would satisfy some use-cases. One idea that comes to
mind is to provide a %-escape for log_filename that expands to the name
of the database encoding (or more likely, some suitable abbrevation).
The logging collector protocol would have to be expanded to include that
information, but that seems do-able.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
