```-----------------------------------------------
Subject: Bug in unicode conversion ...
From: Jan Varga <varga@utcru.sk>
To: t-ishii@sra.co.jp
Date: Sat, 18 Nov 2000 17:41:20 +0100 (CET)


Hi,

I tried this new feature in PostgreSQL. I found one bug.
Script UCS_to_8859.pl skips input lines which
1. code <0x80 or
2. ucs <0x100

I think second one is not good idea because some codes in ISO8859-2
have ucs <0x100 (e.g. 0xE9 - 0x00E9)
```

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

for any other purpose than PGLC_localeconv()'s internal save/restore of
locale settings.  Fix cash.c to call PGLC_localeconv() rather than
making a direct call to localeconv() --- the old way, if PGLC_localeconv()
had already cached a locale result, it would be overwritten by the first
cash_in or cash_out operation, leading to wrong-locale results later.
Probably no demonstrable bug today, since we only appear to be looking
at the LC_MONETARY results which should be the same anyway, but definitely
a gotcha waiting to strike.

sure that broadcast('foo/32') means anything, but if it does, surely
it ought to return foo, not 255.255.255.255.

shifting by the word width is not defined by ANSI C...

re-adopt these settings at every postmaster or standalone-backend startup.
This should fix problems with indexes becoming corrupt due to failure to
provide consistent locale environment for postmaster at all times.  Also,
refuse to start up a non-locale-enabled compilation in a database originally
initdb'd with a non-C locale.  Suppress LIKE index optimization if locale
is not "C" or "POSIX" (are there any other locales where it's safe?).
Issue NOTICE during initdb if selected locale disables LIKE optimization.

other standalone-backend situations) are not duplicated.  Remove some
dead code, add some comments, too.

Accept --help even if no general long options support exists.

with current postmaster.

symlink created by someone else, and therefore modifyable by someone else.

 it fixing Y,YY,YYY,YYYY conversion, the docs and regress tests update
 are included too.

  During the patch testing I found small bug in miscadmin.h in
convertstr() declaration. Here it's fixed too.

 Thanks

        Karel

> > suspect...), so here is an updated patch.
>
> This seems like the wrong way to go about it, because anytime anyone
> changes any elog output anywhere, we'll risk another failure.  If
> syslog can't cope with empty lines, I think the right fix is for the
> output-to-syslog routine to change the data just before sending ---
> then there is only one place to fix.  See the syslog output routine in
> src/backend/utils/error/elog.c.
Makes sense.  Here's a new patch, now the output even looks better:

Larry Rosenman

Anders Bengtsson

a slightly less random order.

non-standard clauses.  Allow CHARACTERISTICS as unquoted identifier.
Merge related reference pages.

Make version.sgml the central place for updating version numbers in the
documentation.  Document titles now contain the version number of the
release they belong to.

filelist.sgml is the central (and only) place to declare system entities
(i.e., sgml files).  No longer a need to declare them in each document
header.

There is no longer any need to maintain duplicate chapter lists in
postgres.sgml and user/admin/etc.sgml, everything is build from the same
sources.  Some parameter entities allow for different text to be included
when the integrated or a single doc set is generated, which eliminates the
problems that had caused this to fail in the past.

Thanks to Brian Hirt for pointing out the performance lossage.

if enable_mergejoin = OFF.  Must do this, because we have no other
implementation method for full joins.

assert_test() functions --- these weren't accomplishing much except to
render the whole module un-loadable ...

from Adriaan Joubert <a.joubert@albourne.com>

From Adriaan Joubert <a.joubert@albourne.com>

standalone, e.g., "./pg_regress int2".

compatibility library which contains a 'main' function, which is not good.
If someone really needed it, think of a different plan.

Improve documentation, too.