Re: JDBC prepared insert and X00 and SQL_ASCII
От | Dave Cramer |
---|---|
Тема | Re: JDBC prepared insert and X00 and SQL_ASCII |
Дата | |
Msg-id | CADK3HH+_FJ-Fn4MOvLZiiXztT9ZR=Tfs4nxMgezUsTFwPCPL7Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: JDBC prepared insert and X00 and SQL_ASCII (gmail Vladimir Koković <vladimir.kokovic@gmail.com>) |
Список | pgsql-hackers |
On Wed, 18 Mar 2020 at 08:56, gmail Vladimir Koković <vladimir.kokovic@gmail.com> wrote:
Hi,
After a thorough Java-Swig-libpq test, I can confirm that INSERT/SELECT is working properly:
1. server_encoding: SQL_ASCII
2. client_encoding: SQL_ASCII
3. INSERT / SELECT java string with x00
libpq, psql - everything is OK !
Vladimir Kokovic, DP senior (69)
Serbia, Belgrade, March 18, 2020On 16.3.20. 17:04, gmail Vladimir Koković wrote:Hi,
I don't know if this is a bug or the intended mode,
but since ODBC works and JDBC does not, I would ask why JDBC prepared insert does not work if ODBC prepared insert works
in case some varchar field contains 0x00 and DB is SQL_ASCII?
I responded on the github issue, but you cannot simply change the client encoding for the JDBC driver. This is not allowed even though there is a setting for allowClientEncodingChanges this is for specific purpose
When using the V3 protocol the driver monitors changes in certain server configuration parameters that should not be touched by end users. The
client_encoding
setting is set by the driver and should not be altered. If the driver detects a change it will abort the connection. There is one legitimate exception to this behaviour though, using the COPY
command on a file residing on the server's filesystem. The only means of specifying the encoding of this file is by altering the client_encoding
setting. The JDBC team considers this a failing of the COPY
command and hopes to provide an alternate means of specifying the encoding in the future, but for now there is this URL parameter. Enable this only if you need to override the client encoding when doing a copy.Dave Cramer
www.postgres.rocks
В списке pgsql-hackers по дате отправления: