are not an alphabetic character although they are not word-breakers too.
So, treat them as part of word.

Per off-list discussion with Dibyendra Hyoju <dibyendra@gmail.com> and
and Bal Krishna Bal <balkrishna7bal@gmail.com> about Nepali language and
Devanagari alphabet.

running pg_restore, which might run in parallel).
Only reopen archive file when we really need to read from it, in parallel code. Otherwise,
close it immediately in a worker, if possible.

exact-match pattern (no wildcard) can be index-optimized in some cases where a
prefix-match pattern cannot; specifically, since the required index clause is
simple equality, it works for regular text/varchar indexes even when the
locale is not C.  I'm not sure how often this case really comes up, but since
it requires hardly any additional work to handle it, we might as well get it
right.  Motivated by a discussion on the JDBC list.

for consistency with the (relatively) recent addition of typmod to SubLink.
An example of why it's a good idea is to be seen in the recent "failed to
locate grouping columns" bug, which wouldn't have happened if a SubPlan
exposed the same typmod info as the SubLink it was derived from.

This could be back-patched, since it doesn't affect any on-disk data format,
but for the moment it doesn't seem necessary to do so.

by the planning process.  This prevents the "failed to locate grouping columns"
error recently reported by Dickson Guedes.  That happens because planning
replaces SubLinks by SubPlans in the subquery's targetlist, and exprTypmod()
is smarter about the former than the latter, causing the apparent type of
the subquery's output columns to change.  This seems to be a deficiency we
should fix in exprTypmod(), but that will be a much more invasive patch
with possible side-effects elsewhere, so I'll do that only in HEAD.

Back-patch to 8.3.  Arguably the lack of a copying step is broken/dangerous
all the way back, but in the absence of known problems I'll refrain from
making the older branches pay the extra cost.  (The reason this particular
symptom didn't appear before is that exprTypmod() wasn't smart about SubLinks
either, until 8.3.)

Patch by Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

Robert Lor

an unlikely call mode, but better be safe.

doesn't matter.  This fixes failures in the Czech locale.

that the data type and GUC accepts.

ITAGAKI Takahiro

Add URL about the Halloween problem.

ENABLE_NLS is not defined, for better compatibility of the backend with
modules compiled the other way.

Per note from Tom after my previous commit.

too, so that the codeset is properly mapped on the newly added PL domains.

instead of just reporting the first one.

Selena Deckelmann

the src/bin/scripts Makefile.

kwlist.h, to avoid having to link the backend object file into other programs
like pg_dump.  We can now simply symlink a single source file from the backend
(kwlookup.c, containing the shared routine ScanKeywordLookup) and compile it
locally, which is a lot cleaner.

amgettuple or only implement amgetbitmap, instead of the former assumption
that every AM supports both APIs.  Extracted with minor editorialization
from Teodor's fast-GIN-insert patch; whatever becomes of that, this seems
like a simple and reasonable generalization of the index AM interface spec.

in favor of log_checkpoints.  Fujii Masao

attribute numbering.  Also, a parent whole-row reference should not require
select privilege on child columns that aren't inherited from the parent.
Problem diagnosed by KaiGai Kohei, though this isn't exactly his patch.

Mauritius began using DST in the summer 2008-2009; the Olson library has been
updated already.

Xavier Bugaud

fail to provide the function itself.  Not sure how we escaped testing anything
later than 7.3 on such cases, but they still exist, as per André Volpato's
report about AIX 5.3.

Per comment from Tom.

Fujii Masao

"syntax error", not the literal string.  I was previously confused on this
matter, but I have now verified that everything is translated properly.

option.  We don't want to commit to what it does, but hiding it will only
cause confusion.

composite, enum and array types, as those are surely not binary-compatible
with anything else because of the embedded OIDs.

Inspired by bug report by Oleg Serov.

unused nonstandard error code that was perhaps intended for this but never
used.

This avoids irritating kernel logs (if system overstep violations are enabled)
and also the grsecurity alert when starting PostgreSQL.

original patch by Jacek Drobiecki

References:
http://archives.postgresql.org/pgsql-bugs/2004-05/msg00103.php
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248967

pg_hba.conf on reload (for example due to a permission error).

Selena Deckelmann

recovery: if background writer or pgstat process dies during recovery (or
any other child process, but those two are the only ones running), send
SIGQUIT to the startup process using correct pid.

As pointed out by ITAGAKI Takahiro, we split SInvalLock into two in 8.4,
so to keep the numbers of the rest of the locks unchanged from 8.3, we
don't need a placeholder.

encoding conversion of any elog/ereport message being sent to the frontend.
This generalizes a patch that I put in last October, which suppressed
translation of only specific messages known to be associated with recursive
can't-translate-the-message behavior.  As shown in bug #4680, we need a more
general answer in order to have some hope of coping with broken encoding
conversion setups.  This approach seems a good deal less klugy anyway.

Patch in all supported branches.

- pg_wchar and wchar_t could have different size, so char2wchar
  doesn't call pg_mb2wchar_with_len to prevent out-of-bound
  memory bug
- make char2wchar/wchar2char symmetric, now they should not be
  called with C-locale because mbstowcs/wcstombs oftenly doesn't
  work correct with C-locale.
- Text parser uses pg_mb2wchar_with_len directly in case of
  C-locale and multibyte encoding

Per bug report by Hiroshi Inoue <inoue@tpf.co.jp> and
following discussion.

Backpatch up to 8.2 when multybyte support was implemented in tsearch.

fail on zero-length inputs.  This isn't an issue in normal use because the
conversion infrastructure skips calling the converters for empty strings.
However a problem was created by yesterday's patch to check whether the
right conversion function is supplied in CREATE CONVERSION.  The most
future-proof fix seems to be to make the converters safe for this corner case.

input lists before we grovel through the lists.  This doesn't save much,
but testing shows that the case of both inputs NIL is common enough that
it saves something.  And this is used enough to be a hotspot.

to 100ms (from 1000).  This still seems to be comfortably larger than the
useful range of the parameter, and it should help discourage people from
picking uselessly large values.  Tweak the documentation to recommend small
values, too.  Per discussion of a couple weeks ago.