From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp>, Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: encoding of PostgreSQL messages |
Date: | 2009-02-08 15:38:16 |
Message-ID: | 19896.1234107496@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Bruce Momjian wrote:
>> Can someone comment on this?
> Looks like a horrible hack to me. Recoding stuff to the client encoding
> in the server outside the existing recoding mechanism looks pretty evil
> to me. Plus, it does not address the problem of what happens to
> messages sent before this, it just moves the point of "before" a bit
> earlier for some special cases.
> I think we have discussed more proper solutions earlier in this thread.
> IMO the best approach would be for the client to include the client
> encoding in the startup package.
Huh? Clients already do that (or at least some are capable of it,
including libpq). The hard problems are (1) there's still a "before",
ie we might fail before scanning the options in the packet, and (2)
the sent encoding might itself be invalid, and you still have to report
that somehow.
I believe the only real "fix" is to guarantee that messages are sent
as untranslated ASCII until we have sent an encoding indicator at
the end of the startup sequence. Which has its own pretty clear
downside: no more translation of authorization failures.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Iñigo Barandiaran | 2009-02-08 15:46:59 | Re: Install Postgre while installing Other software. |
Previous Message | Josh Harrison | 2009-02-08 15:18:27 | problem connecting oracle and postgres database |