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 по дате отправления:

Предыдущее
От: Oliver Jowett
Дата:
Сообщение: Re: 8.0.0beta4: "copy" and "client_encoding"
Следующее
От: "J. Michael Crawford"
Дата:
Сообщение: Re: [GENERAL] Using Postgres with Latin1 (ISO8859-1)