Re: encoding of PostgreSQL messages

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

In response to

Responses

Browse pgsql-general by date

  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