Craig Ringer <cr...@postnewspapers.com.au> writes:
> On 22/09/2010 5:45 PM, Peter Eisentraut wrote:
>> We need to produce the log output in the server encoding, because that's
>> how we need to send it to the client.
> That doesn't mean it can't be recoded for writing to the log file,
> though. Perhaps it needs to be. It should be reasonably practical to
> detect when the database and log encoding are the same and avoid the
> transcoding performance penalty, not that it's big anyway.
We have seen ... and rejected ... such proposals before. The problem is
that "transcode to some other encoding" is not a simple and guaranteed
error-free operation. As an example, if you choose to name some table
using a character that doesn't exist in the log encoding, you have just
ensured that no message about that table will ever get to the log.
Nice way to hide your activities from the DBA ;-) Transcoding also
eats memory, which might be in exceedingly short supply while trying
to report an "out of memory" error; and IIRC there are some other
failure scenarios to be concerned about.
We could maybe accept a design for this that included a sufficiently
well-thought-out set of fallback behaviors. But we haven't seen one
yet.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
