Re: 8.0.0beta4: "copy" and "client_encoding" - Mailing list pgsql-jdbc

From Barry Lind
Subject Re: 8.0.0beta4: "copy" and "client_encoding"
Date
Msg-id 03E7D3E231BB7B4A915A6581D4296CC6C083E1@NSNOVPS00411.nacio.xythos.com
Whole thread Raw
In response to 8.0.0beta4: "copy" and "client_encoding"  (mbch67@yahoo.com)
Responses Re: 8.0.0beta4: "copy" and "client_encoding"
List 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 by date:

Previous
From: Oliver Jowett
Date:
Subject: Re: 8.0.0beta4: "copy" and "client_encoding"
Next
From: "J. Michael Crawford"
Date:
Subject: Re: [GENERAL] Using Postgres with Latin1 (ISO8859-1)