Re: 8.0.0beta4: "copy" and "client

Barry Lind

unread,

Nov 6, 2004, 12:21:47 AM11/6/04

to

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:bo...@ejurka.com]
Sent: Friday, November 05, 2004 12:28 PM
To: Markus Schaber
Cc: Oliver Jowett; pgsql...@postgresql.org; mbc...@yahoo.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 majo...@postgresql.org)

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Oliver Jowett

unread,

Nov 8, 2004, 5:07:12 PM11/8/04

to

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

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Barry Lind

unread,

Nov 8, 2004, 7:09:13 PM11/8/04

to

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:oli...@opencloud.com]
Sent: Monday, November 08, 2004 2:07 PM
To: Barry Lind
Cc: Kris Jurka; Markus Schaber; pgsql...@postgresql.org;
mbc...@yahoo.com
Subject: Re: [JDBC] 8.0.0beta4: "copy" and "client_encoding"

-O

---------------------------(end of broadcast)---------------------------

Kris Jurka

unread,

Nov 8, 2004, 7:28:40 PM11/8/04

to

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
>

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Markus Schaber

unread,

Nov 9, 2004, 12:33:02 PM11/9/04

to

Hi, Kris,

On Fri, 5 Nov 2004 15:27:51 -0500 (EST)
Kris Jurka <bo...@ejurka.com> wrote:

> 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 would prefer to adding the URL option, maybe combined with the version
compatibility flag.

Adding an API always carries the disadvantage that the user has to do
runtime casts and add special cased code even when the sql syntax is
compatible for all capable servers.

Have fun,
Markus

Markus Schaber

unread,

Nov 9, 2004, 12:36:26 PM11/9/04

to

Hi, Oliver,

On Tue, 09 Nov 2004 11:07:12 +1300
Oliver Jowett <oli...@opencloud.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

---------------------------(end of broadcast)---------------------------

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

Barry Lind

Oliver Jowett

Barry Lind

Kris Jurka

Markus Schaber

Markus Schaber