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
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 |