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)

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

Hi, Oliver,

On Tue, 09 Nov 2004 11:07:12 +1300
Oliver Jowett <oliver(at)opencloud(dot)com> 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?

The upgrade path is to use properly recoded files.

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

Maybe the sanest way would be to have an extra parameter, but setting
compatible=7.4 also disables the check.

But this may be to confusing.

Markus

--
markus schaber | dipl. informatiker
logi-track ag | rennweg 14-16 | ch 8001 zürich
phone +41-43-888 62 52 | fax +41-43-888 62 53
mailto:schabios(at)logi-track(dot)com | www.logi-track.com