Re: preventing encoding conversion while starting up

> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> > BTW, for the problem I reported, what about checking
> > IsTransactionState returns true before accessing database to find out
> > conversions?
> 
> 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?

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. Currently guc assumes the default encoding for
client is SQL_ASCII until the conversion system finds requested client
encoding (actually conversion system itself regards SQL_ASCII is
default). This is actualy unnecessary right now, but it would minimize
possible problem in the future. Ideally there should be a special
encoding "NO_CONVERSION", people seem to treat SQL_ASCII to be almost
identical to it anyway (remember the days when multibyte was optional).
--
Tatsuo Ishii