X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
	by postgresql.org (Postfix) with ESMTP id 921969DD619
	for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
	Tue,  6 Dec 2005 16:47:31 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 90319-03
	for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
	Tue,  6 Dec 2005 16:47:32 -0400 (AST)
X-Greylist: domain auto-whitelisted by SQLgrey-
Received: from mail.gmx.net (mail.gmx.de [213.165.64.20])
	by postgresql.org (Postfix) with SMTP id 0BBD69DD61C
	for <pgsql-hackers@postgresql.org>;
	Tue,  6 Dec 2005 16:47:27 -0400 (AST)
Received: (qmail invoked by alias); 06 Dec 2005 20:47:28 -0000
Received: from dslb-084-063-064-101.pools.arcor-ip.net (EHLO colt.pezone.net)
	[84.63.64.101]
	by mail.gmx.net (mp015) with SMTP; 06 Dec 2005 21:47:28 +0100
X-Authenticated: #495269
From: Peter Eisentraut <peter_e@gmx.net>
To: pgsql-hackers@postgresql.org
Subject: Re: Upcoming PG re-releases
Date: Tue, 6 Dec 2005 21:47:25 +0100
User-Agent: KMail/1.8.2
Cc: Bruce Momjian <pgman@candle.pha.pa.us>
References: <200512062025.jB6KPDK02212@candle.pha.pa.us>
In-Reply-To: <200512062025.jB6KPDK02212@candle.pha.pa.us>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200512062147.26826.peter_e@gmx.net>
X-Y-GMX-Trusted: 0
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, score=0.515 required=5 tests=[AWL=0.515]
X-Spam-Score: 0.515
X-Spam-Level: 
X-Archive-Number: 200512/334
X-Sequence-Number: 77182

Bruce Momjian wrote:
> One nice solution would be if iconv would report the lines with
> errors and you could correct them, but I see no way to do that.  The
> only thing you could do is to diff the old and new files to see the
> problems.  Is that helpful?  Here is new text I have used:

I think this is nice.  It users see a big mess, they will have to clean
it up by hand anyway.

How about this for better wording:

diff -u -3 -p -r1.400.2.4 release.sgml
--- doc/src/sgml/release.sgml   6 Dec 2005 20:26:02 -0000       1.400.2.4
+++ doc/src/sgml/release.sgml   6 Dec 2005 20:44:26 -0000
@@ -528,15 +528,16 @@ psql -t -f fixseq.sql db1 | psql -e db1

      <listitem>
       <para>
-       Some users are having problems loading <literal>UTF8</> data into
-       8.1.X.  This is because previous versions allowed invalid <literal>UTF8</>
+       Some users are having problems loading UTF-8 data into
+       8.1.X.  This is because previous versions allowed invalid UTF-8 byte
        sequences to be entered into the database, and this release
-       properly accepts only valid <literal>UTF8</> sequences.  One
-       way to correct a dumpfile is to use <command>iconv -c -f UTF-8 -t UTF-8
+       properly accepts only valid UTF-8 sequences.  One
+       way to correct a dumpfile is to run the command <command>iconv -c -f UTF-8 -t UTF-8
        -o cleanfile.sql dumpfile.sql</>.  The <literal>-c</> option removes
        invalid character sequences.  A diff of the two files will show the
        sequences that are invalid.  <command>iconv</> reads the entire input
-       file into memory so it might be necessary to <command>split</> the dump
+       file into memory so it might be necessary to use <command>split</>
+       to break up the dump
        into multiple smaller files for processing.
       </para>
      </listitem>

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/