Re: COPY command character set

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Peter Headland <pheadland(at)actuate(dot)com>
Cc: Adrian Klaver <aklaver(at)comcast(dot)net>, pgsql-general(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: COPY command character set
Date: 2010-02-23 05:17:45
Message-ID: 201002230517.o1N5Hj006114@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


I have updated the documentation to be more direct about COPY encoding
behavior. Patch attached and applied.

---------------------------------------------------------------------------

Peter Headland wrote:
> > Maybe the link might help?
> >
> > http://www.postgresql.org/docs/8.4/interactive/multibyte.html
>
> That page is too generic; what would be helpful is a section in the doc for each command that is affected by I18N/L10N considerations, that identifies how that specific command behaves.
>
> Now that I have grasped the behavior, I'm more than happy to edit the COPY doc page, if people think that would be helpful/worthwhile.
>
> --
> Peter Headland
> Architect
> Actuate Corporation
>
>
> -----Original Message-----
> From: Adrian Klaver [mailto:aklaver(at)comcast(dot)net]
> Sent: Thursday, September 10, 2009 11:06
> To: Peter Headland
> Cc: pgsql-general(at)postgresql(dot)org; Tom Lane
> Subject: Re: [GENERAL] COPY command character set
>
>
> ----- "Peter Headland" <pheadland(at)actuate(dot)com> wrote:
>
> > > The COPY command reference page saith
> > >
> > > Input data is interpreted according to the current client
> > encoding,
> > > and output data is encoded in the the current client encoding,
> > even
> > > if the data does not pass through the client but is read from or
> > > written to a file.
> >
> > Rats - I read the manual page twice and that didn't register on my
> > feeble consciousness. I suspect that I didn't look beyond the word
> > "client", since I knew I wasn't interested in client behavior and I
> > was
> > speed-reading. On the assumption that I am not uniquely stupid, maybe
> > we
> > could re-phrase this slightly, with a "for example", and add a
> > heading
> > "Localization"?
> >
> > As a general comment, I18N/L10N is a hairy enough topic that it
> > merits
> > its own heading in any commands where it is an issue.
> >
> > How about my suggestion to add a means (extend COPY syntax) to
> > specify
> > encoding explicitly and handle UTF lead bytes - would that be of
> > interest?
> >
> > --
> > Peter Headland
> > Architect
> > Actuate Corporation
> >
>
> >
> > The COPY command reference page saith
> >
> > Input data is interpreted according to the current client
> > encoding,
> > and output data is encoded in the the current client encoding,
> > even
> > if the data does not pass through the client but is read from or
> > written to a file.
> >
> > Seems clear enough to me.
> >
> > regards, tom lane
>
> Maybe the link might help?
>
> http://www.postgresql.org/docs/8.4/interactive/multibyte.html
>
>
> Adrian Klaver
> aklaver(at)comcast(dot)net
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
+ If your life is a hard drive, Christ can be your backup. +

Attachment Content-Type Size
/rtmp/diff text/x-diff 960 bytes

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2010-02-23 05:31:27 Re: comment on constraint
Previous Message John R Pierce 2010-02-23 05:09:56 Re: how do I do dump and restore without bugging with constraint?