Re: 8.0.0beta4: "copy" and "client_encoding"
От | Barry Lind |
---|---|
Тема | Re: 8.0.0beta4: "copy" and "client_encoding" |
Дата | |
Msg-id | 03E7D3E231BB7B4A915A6581D4296CC6C083E1@NSNOVPS00411.nacio.xythos.com обсуждение исходный текст |
Ответ на | 8.0.0beta4: "copy" and "client_encoding" (mbch67@yahoo.com) |
Ответы |
Re: 8.0.0beta4: "copy" and "client_encoding"
|
Список | pgsql-jdbc |
I am assuming this will get addressed in the backend in 8.1 and that would be the upgrade path. (I agree if there isn't agreement on the server side that this is appropriate for the server, then this wouldn't be the correct parameter). --Barry -----Original Message----- From: Oliver Jowett [mailto:oliver@opencloud.com] Sent: Monday, November 08, 2004 2:07 PM To: Barry Lind Cc: Kris Jurka; Markus Schaber; pgsql-jdbc@postgresql.org; mbch67@yahoo.com Subject: Re: [JDBC] 8.0.0beta4: "copy" and "client_encoding" Barry Lind wrote: > If you choose to go the URL parameter route, I would suggest you use > the existing 'compatible' parameter. This is exactly the type of > thing that parameter was designed to be used for. By default the > driver does the new check. But with a value of 'compatible=7.4' (or > less, i.e. < 8.0) the driver would revert back to the old behavior of > not doing this check. What's the upgrade path for a "legacy" application that uses COPY, so that it is a "current" application and no longer needs the compatible= parameter? I don't see such a path without an additional COPY API or backend changes. So I'd prefer not to put this into the "compatible behaviour" bucket. -O
В списке pgsql-jdbc по дате отправления: