Re: 8.0.0beta4: "copy" and "client_encoding"

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(at)opencloud(dot)com]
Sent: Monday, November 08, 2004 2:07 PM
To: Barry Lind
Cc: Kris Jurka; Markus Schaber; pgsql-jdbc(at)postgresql(dot)org;
mbch67(at)yahoo(dot)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

Well, lets ask -hackers...

When COPYing data from a file, the file encoding is taken from the
client_encoding parameter. The JDBC driver always uses UNICODE as the
client_encoding and wants to prevent people from changing it by
monitoring ParameterStatus messages and erroring out if it's changed.
This presents a problem when you want to COPY to or from a file with a
different encoding. It seems reasonable to add an ENCODING specification
to the COPY command instead of relying on the somewhat unrelated
client_encoding setting. Oliver Jowett also noted that copying from a
file with LATIN1 data into a table whose name contained UNICODE characters
could not be done. Does this seem like a reasonable thing to do?

Kris Jurka

On Mon, 8 Nov 2004, Barry Lind wrote:

> 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
>