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

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.

--Barry

-----Original Message-----
From: Kris Jurka [mailto:books(at)ejurka(dot)com]
Sent: Friday, November 05, 2004 12:28 PM
To: Markus Schaber
Cc: Oliver Jowett; pgsql-jdbc(at)postgresql(dot)org; mbch67(at)yahoo(dot)com
Subject: Re: [JDBC] 8.0.0beta4: "copy" and "client_encoding"

On Fri, 5 Nov 2004, Markus Schaber wrote:

> I think you're right. Except COPY from STDIN, client encoding should
> be independent from COPY encoding. So I suggest that Adrian requests
> backend support for this.
>

Well that's not going to get in for 8.0, so we'll need to do something
especially since the driver is supposed to offer backward compatibility.

From my perspective we've got three options, just drop the check,
Oliver's add a URL parameter to turn off the check, or add an API so
that they don't issue the COPY command directly, but something like
issueServerCopy(table, file, encoding) where the driver could turn off
the check, switch the encoding, do the copy, switch the encoding back,
and turn on the check.

I think the third option is too much work at the moment, when we do
offer a copy API in the driver we could fold that in, but not now. As
to the first two options, I don't really care. Either is fine with me,
so since Oliver seems to like a URL parameter, that's what we'll
probably go with.

Kris Jurka

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)