Tatsuo Ishii <t-ishii@sra.co.jp> writes:
>> The $64 problem here is *what do you do before you can access the database*.
>> Detecting whether you can access the database yet is irrelevant unless
>> you can say what you're going to do when the answer is "no".
> Of course we could do no encoding conversion if the answer is "no".
> What's wrong with this?
Maybe nothing, if that's what the clients will expect.
I don't actually much care for using IsTransactionState() to try to
determine whether it's safe to look at the database. I'd suggest that
the conversion system start up in the no-conversions state, and change
over to doing a conversion only when explicitly told to --- which would
happen in the same late phase of startup that it used to (near the
SetConfigOption("client_encoding") calls), or at subsequent SET
commands. In other words, keep the database lookups firmly out of the
conversion system proper, and have it do only what it's told. This
seems much safer than doing a lookup at whatever random time a message
is generated.
> Also I'm thinking about treating SQL_ASCII encoding as "special": if
> database or client encoding is SQL_ASCII, then we could alwasy avoid
> encoding conversion.
Good idea. I was somewhat troubled by the prospect of added overhead
for people who didn't need multibyte at all --- wasn't there a
commitment that there wouldn't be any noticeable slowdown from enabling
multibyte all the time?
regards, tom lane
