Re: minor changes in psql's \encoding command

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Weiping He <laser(at)zhengmai(dot)com(dot)cn>, pgsql-patches(at)postgresql(dot)org
Subject: Re: minor changes in psql's \encoding command
Date: 2003-01-05 05:54:35
Message-ID: 6800.1041746075@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Should we throw a warning when the do it?

How? The backend can't throw such a warning (it has no way to know if
the SET is coming from the client library or a higher level). The only
way to do it would be for the client library to parse every command
passed through it to look for "SET client_encoding" ... which is
expensive and still not very bulletproof.

Perhaps in the still-mythical 7.4 protocol revision, we could consider
adding a field to backend result messages to show the current client
encoding. But I misdoubt whether it's worth adding a couple bytes to
*every* backend message to make life safe for clients who both want to
change the encoding on the fly, and want to do so behind the back of the
low-level libraries they're using. That's a cost paid by everyone to
satisfy a very small group.

I really think that documentation to the effect of "don't do it this
way, do it that other way" is the appropriate solution.

regards, tom lane

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Neil Conway 2003-01-05 18:02:12 Re: disabled, deferred triggers
Previous Message Bruce Momjian 2003-01-05 05:46:05 Re: minor changes in psql's \encoding command