Remove tabs from SGML.

Re-add documentation for --no-readline option of psql, mistakenly removed a decade ago. Backpatch to release 7.4.

Try to defend against the possibility that libpq is still in COPY_IN state
when we reach the post-COPY "pump it dry" error recovery code that was added
2006-11-24.  Per a report from Neil Best, there is at least one code path
in which this occurs, leading to an infinite loop in code that's supposed
to be making it more robust not less so.  A reasonable response seems to be
to call PQputCopyEnd() again, so let's try that.

Back-patch to all versions that contain the cleanup loop.

Fix xslt_process() to ensure that it inserts a NULL terminator after the
last pair of parameter name/value strings, even when there are MAXPARAMS
of them.  Aboriginal bug in contrib/xml2, noted while studying bug #4912
(though I'm not sure whether there's something else involved in that
report).

This might be thought a security issue, since it's a potential backend
crash; but considering that untrustworthy users shouldn't be allowed
to get their hands on xslt_process() anyway, it's probably not worth
getting excited about.

Fix ancient bug in handling of to_char modifier 'TH', when used with HH.
In what seems like an oversight, we used to treat 'TH' the same as lowercase
'th', but only with HH/HH12.

Fix an ancient error in dist_ps (distance from point to line segment), which
a number of other geometric operators also depend on.  It miscalculated the
slope of the perpendicular to the given line segment anytime that slope was
other than 0, infinite, or +/-1.  In some cases the error would be masked
because the true closest point on the line segment was one of its endpoints
rather than the intersection point, but in other cases it could give an
arbitrarily bad answer.  Per bug #4872 from Nick Roosevelt.

Bug goes clear back to Berkeley days, so patch all supported branches.
Make a couple of cosmetic adjustments while at it.

Update time zone data files to tzdata release 2009i: DST law changes in
Bangladesh, Egypt, Jordan, Pakistan.

Improve capitalization and punctuation in recently added GiST message.

Fix cash_in() to behave properly in locales where frac_digits is zero,
eg Japan.  Report and fix by Itagaki Takahiro.  Also fix CASHDEBUG printout
format for branches with 64-bit money type, and some minor comment cleanup.

Back-patch to 7.4, because it's broken all the way back.

Adjust recent PERL_SYS_INIT3 call to avoid platforms where it might fail, and to remove compilation warning. Backpatch the release 7.4

Initialise perl library as documented in perl API. Backpatch to release 7.4.

Split the release notes into a separate file for each (active) major branch,
as per my recent proposal.  release.sgml itself is now just a stub that should
change rarely; ideally, only once per major release to add a new include line.
Most editing work will occur in the release-N.N.sgml files.  To update a back
branch for a minor release, just copy the appropriate release-N.N.sgml
file(s) into the back branch.

This commit doesn't change the end-product documentation at all, only the
source layout.  However, it makes it easy to start omitting ancient information
from newer branches' documentation, should we ever decide to do that.

When checking for datetime field overflow, we should allow a fractional-second
part that rounds up to exactly 1.0 second.  The previous coding rejected input
like "00:12:57.9999999999999999999999999999", with the exact number of nines
needed to cause failure varying depending on float-timestamp option and
possibly on platform.  Obviously this should round up to the next integral
second, if we don't have enough precision to distinguish the value from that.
Per bug #4789 from Robert Kruus.

In passing, fix a missed check for fractional seconds in one copy of the
"is it greater than 24:00:00" code.

Broken all the way back, so patch all the way back.

Fix the handling of sub-SELECTs appearing in the arguments of an outer-level
aggregate function.  By definition, such a sub-SELECT cannot reference any
variables of query levels between itself and the aggregate's semantic level
(else the aggregate would've been assigned to that lower level instead).
So the correct, most efficient implementation is to treat the sub-SELECT as
being a sub-select of that outer query level, not the level the aggregate
syntactically appears in.  Not doing so also confuses the heck out of our
parameter-passing logic, as illustrated in bug report from Daniel Grace.

Fortunately, we were already copying the whole Aggref expression up to the
outer query level, so all that's needed is to delay SS_process_sublinks
processing of the sub-SELECT until control returns to the outer level.

This has been broken since we introduced spec-compliant treatment of
outer aggregates in 7.4; so patch all the way back.

Remove HELIOS Software GmbH name and copyright from AIX dynloader files,
per approval from Helmut Tschemernjak, President.

Only back branches;  files removed from CVS HEAD.

Remove beer-ware license from crypt-md5.c, per
approval from Poul-Henning Kamp.

This makes the file the same standard 2-clause BSD as the
rest of PostgreSQL.

Update time zone data files to tzdata release 2009e: DST law changes in
Argentina/San_Luis, Cuba, Jordan (historical correction only), Morocco,
Palestine, Syria, Tunisia.

Fix 'all at one page bug' in picksplit method of R-tree emulation. Add defense
from buggy user-defined picksplit to GiST.

Defend against non-ASCII letters in fuzzystrmatch code.  The functions
still don't behave very sanely for multibyte encodings, but at least
they won't be indexing off the ends of static arrays.

Rewrite interval_hash() so that the hashcodes are equal for values that
interval_eq() considers equal.  I'm not sure how that fundamental requirement
escaped us through multiple revisions of this hash function, but there it is;
it's been wrong since interval_hash was first written for PG 7.1.
Per bug #4748 from Roman Kononov.

Backpatch to all supported releases.

This patch changes the contents of hash indexes for interval columns.  That's
no particular problem for PG 8.4, since we've broken on-disk compatibility
of hash indexes already; but it will require a migration warning note in
the next minor releases of all existing branches: "if you have any hash
indexes on columns of type interval, REINDEX them after updating".

Fix contrib/pgstattuple and contrib/pageinspect to prevent attempts to read
temporary tables of other sessions; that is unsafe because of the way our
buffer management works.  Per report from Stuart Bishop.
This is redundant with the bufmgr.c checks in HEAD, but not at all redundant
in the back branches.

Don't crash initdb when we fail to get the current username.
Give an error message and exit instead, like we do elsewhere...

Per report from Wez Furlong and Robert Treat.

tag 8.0.21

Update back-branch release notes.

Fix core dump due to null-pointer dereference in to_char() when datetime
format codes are misapplied to a numeric argument.  (The code still produces
a pretty bogus error message in such cases, but I'll settle for stopping the
crash for now.)  Per bug #4700 from Sergey Burladyan.

Problem exists in all supported branches, so patch all the way back.
In HEAD, also clean up some ugly coding in the nearby cache management
code.

Add MUST (Mauritius Island Summer Time) to the list of known abbreviations.
Mauritius began using DST in the summer 2008-2009; the Olson library has been
updated already.

Xavier Bugaud

Put back our old workaround for machines that declare cbrt() in math.h but
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.

Ooops ... fix some confusion between gettext() and _() in my previous patch.
This has moved around in past releases, so just copying-and-pasting from HEAD
didn't work as intended.

When we are in error recursion trouble, arrange to suppress translation and
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.

Fix buffer allocations in encoding conversion routines so that they won't
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.

In CREATE CONVERSION, test that the given function is a valid conversion
function for the specified source and destination encodings. We do that by
calling the function with an empty string. If it can't perform the requested
conversion, it will throw an error.

Backport to 7.4 - 8.3. Per bug report #4680 by Denis Afonin.

commit first then tag 8.0.20

Update back-branch release notes.

Translation updates

Update time zone data files to tzdata release 2009a: introduces Asia/Kathmandu
as the preferred spelling of that zone name, corrects historical DST
information for Switzerland and Cuba.

Replace argument-checking Asserts with regular test-and-elog checks in all
encoding conversion functions.  These are not can't-happen cases because
it's possible to create a conversion with the wrong conversion function
for the specified encoding pair.  That would lead to an Assert crash in
an Assert-enabled build, or incorrect conversion otherwise, neither of
which is desirable.  This would be a DOS issue if production databases
were customarily built with asserts enabled, but fortunately that's not so.
Per an observation by Heikki.

Back-patch to all supported branches.

Go over all OpenSSL return values and make sure we compare them
to the documented API value. The previous code got it right as
it's implemented, but accepted too much/too little compared to
the API documentation.

Per comment from Zdenek Kotala.

Fix uninitialized variables in get_covers

Fix URL generation in headline. Only tag lexeme will be replaced by space.
Per http://archives.postgresql.org/pgsql-bugs/2008-12/msg00013.php

Fix generation of too long headline with ShortWords.
Per http://archives.postgresql.org/pgsql-hackers/2008-09/msg01088.php

Remove references to pgsql-ports and pgsql-patches mailing lists from
various documentation, since those lists are now dead/deprecated.
Point to pgsql-bugs and/or pgsql-hackers as appropriate.

Fix logic in lazy vacuum to decide if it's worth trying to truncate the heap.
If the table was smaller than REL_TRUNCATE_FRACTION (= 16) pages, we always
tried to acquire AccessExclusiveLock on it even if there was no empty pages
at the end.

Report by Simon Riggs. Back-patch all the way to 7.4.

tag for 8.0.19

Update back-branch release notes.

Translation updates

Update time zone data files to tzdata release 2008i (DST law changes in
Argentina, Brazil, Mauritius, Syria).

Missing space in error message

Install a more robust solution for the problem of infinite error-processing
recursion when we are unable to convert a localized error message to the
client's encoding.  We've been over this ground before, but as reported by
Ibrar Ahmed, it still didn't work in the case of conversion failures for
the conversion-failure message itself :-(.  Fix by installing a "circuit
breaker" that disables attempts to localize this message once we get into
recursion trouble.

Patch all supported branches, because it is in fact broken in all of them;
though I had to add some missing translations to the older branches in
order to expose the failure in the particular test case I was using.

Fix an old bug in after-trigger handling: AfterTriggerEndQuery took the
address of afterTriggers->query_stack[afterTriggers->query_depth] and hung
onto it through all its firings of triggers.  However, if a trigger causes
sufficiently many nested query executions, query_stack will get repalloc'd
bigger, leaving AfterTriggerEndQuery --- and hence afterTriggerInvokeEvents
--- using a stale pointer.

So far as I can find, the only consequence of this error is to stomp on a
couple of words of already-freed memory; which would lead to a failure only if
that chunk had already gotten re-allocated for something else.  So it's hard
to exhibit a simple failure case, but this is surely a bug.

I noticed this while working on my recent patch to reduce pending-trigger
space usage.  The present patch is mighty ugly, because it requires making
afterTriggerInvokeEvents know about all the possible event lists it might get
called on.  Fortunately, this is only needed in back branches because CVS HEAD
avoids the problem in a different way: afterTriggerInvokeEvents only touches
the passed AfterTriggerEventList pointer once at startup.  Back branches are
stable enough that wiring in knowledge of all possible call usages doesn't
seem like a killer problem.

Back-patch to 8.0.  7.4's trigger code is completely different and doesn't
seem to have the problem (it doesn't even use repalloc).

Fix small bug in headline generation.
Patch from Sushant Sinha <sushant354@gmail.com>
http://archives.postgresql.org/pgsql-hackers/2008-07/msg00785.php

Fix SPI_getvalue and SPI_getbinval to range-check the given attribute number
according to the TupleDesc's natts, not the number of physical columns in the
tuple.  The previous coding would do the wrong thing in cases where natts is
different from the tuple's column count: either incorrectly report error when
it should just treat the column as null, or actually crash due to indexing off
the end of the TupleDesc's attribute array.  (The second case is probably not
possible in modern PG versions, due to more careful handling of inheritance
cases than we once had.  But it's still a clear lack of robustness here.)

The incorrect error indication is ignored by all callers within the core PG
distribution, so this bug has no symptoms visible within the core code, but
it might well be an issue for add-on packages.  So patch all the way back.

Optional argument should be optional.

Fix overly tense optimization of PLpgSQL_func_hashkey: we must represent
the isTrigger state explicitly, not rely on nonzero-ness of trigrelOid
to indicate trigger-hood, because trigrelOid will be left zero when compiling
for validation.  The (useless) function hash entry built by the validator
was able to match an ordinary non-trigger call later in the same session,
thereby bypassing the check that is supposed to prevent such a call.
Per report from Alvaro.

It might be worth suppressing the useless hash entry altogether, but
that's a bigger change than I want to consider back-patching.

Back-patch to 8.0.  7.4 doesn't have the problem because it doesn't
have validation mode.

Fix improper display of fractional seconds in interval values
when using --enable-integer-datetimes and a non-ISO datestyle.

Ron Mayer

Recent patches to pg_ctl broke "pg_ctl restart" for the case where no
command-line options had been given to the postmaster; and just plain
broke it altogether in 8.1 and 8.0.  Per report from KaiGai Kohei.

tag for 8.0.18

Update back-branch release notes.

Update time zone data files to tzdata release 2008f (DST law changes in
Argentina, Bahamas, Brazil, Mauritius, Morocco, Pakistan, Palestine, Paraguay).

Widen the nLocks counts in local lock tables from int to int64.  This
forestalls potential overflow when the same table (or other object, but
usually tables) is accessed by very many successive queries within a single
transaction.  Per report from Michael Milligan.

Back-patch to 8.0, which is as far back as the patch conveniently applies.
There have been no reports of overflow in pre-8.3 releases, but clearly the
risk existed all along.  (Michael's report suggests that 8.3 may consume lock
counts faster than prior releases, but with no test case to look at it's hard
to be sure about that.  Widening the counts seems a good future-proofing
measure in any event.)

Fix pg_dump docs to acknowledge that you can use -Z with plain text output.  Pointed out by Daniel Migowski.

Fix pg_dump/pg_restore's ExecuteSqlCommand() to behave suitably if PQexec
returns NULL instead of a PGresult.  The former coding would fail, which
is OK, but it neglected to give you the PQerrorMessage that might tell
you why.  In the oldest branches, there was another problem: it'd sometimes
report PQerrorMessage from the wrong connection.

Install checks in executor startup to ensure that the tuples produced by an
INSERT or UPDATE will match the target table's current rowtype.  In pre-8.3
releases inconsistency can arise with stale cached plans, as reported by
Merlin Moncure.  (We patched the equivalent hazard on the SELECT side in Feb
2007; I'm not sure why we thought there was no risk on the insertion side.)
In 8.3 and HEAD this problem should be impossible due to plan cache
invalidation management, but it seems prudent to make the check anyway.

Back-patch as far as 8.0.  7.x versions lack ALTER COLUMN TYPE, so there
seems no way to abuse a stale plan comparably.

Do not allow Unique nodes to be scanned backwards.  The code claimed that it
would work, but in fact it didn't return the same rows when moving backwards
as when moving forwards.  This would have no visible effect in a DISTINCT
query (at least assuming the column datatypes use a strong definition of
equality), but it gave entirely wrong answers for DISTINCT ON queries.

Update 8.1 and 8.0 plpython to work with Python 2.5.  This backports several
fixes made during the 8.2 development cycle, but not backported at the time
for lack of confidence in the new coding.

I didn't touch 7.4 because it has more problems than this: the configure
probe for Python fails.

Fix performance bug in write_syslog(): the code to preferentially break the
log message at newlines cost O(N^2) for very long messages with few or no
newlines.  For messages in the megabyte range this became the dominant cost.
Per gripe from Achilleas Mantzios.

Patch all the way back, since this is a safe change with no portability
risks.  I am also thinking of increasing PG_SYSLOG_LIMIT, but that should
be done separately.

Fix estimate_num_groups() to assume that GROUP BY expressions yielding boolean
results always contribute two groups, regardless of the expression contents.
This is very substantially more accurate than the regular heuristic for
certain boolean tests like "col IS NULL".  Per gripe from Sam Mason.

Back-patch to all supported releases, since the behavior of
estimate_num_groups() hasn't changed all that much since 7.4.

Fix identify_system_timezone() so that it tests the behavior of the system
timezone setting in the current year and for 100 years back, rather than
always examining years 1904-2004.  The original coding would have problems
distinguishing zones whose behavior diverged only after 2004; which is a
situation we will surely face sometime, if it's not out there already.

In passing, also prevent selection of the dummy "Factory" timezone, even
if that's exactly what the system is using.  Reporting time as GMT seems
better than that.

Fix 'pg_ctl reload' to properly preserve postmaster commend-line
arguments on restart.  Patch to releases 8.0 - 8.3.X.

Clean up a number of bogosities around pltcl's handling of the Tcl "result":

1. Directly reading interp->result is deprecated in Tcl 8.0 and later;
you're supposed to use Tcl_GetStringResult.  This code finally broke with
Tcl 8.5, because Tcl_GetVar can now have side-effects on interp->result even
though it preserves the logical state of the result.  (There's arguably a
Tcl issue here, because Tcl_GetVar could invalidate the pointer result of a
just-preceding Tcl_GetStringResult, but I doubt the Tcl guys will see it as
a bug.)

2. We were being sloppy about the encoding of the result: some places would
push database-encoding data into the Tcl result, which should not happen,
and we were assuming that any error result coming back from Tcl was in the
database encoding, which is not a good assumption.

3. There were a lot of calls of Tcl_SetResult that uselessly specified
TCL_VOLATILE for constant strings.  This is only a minor performance issue,
but I fixed it in passing since I had to look at all the calls anyway.

#2 is a live bug regardless of which Tcl version you are interested in,
so back-patch even to branches that are unlikely to be used with Tcl 8.5.
I went back as far as 8.0, which is as far as the patch applied easily;
7.4 was using a different error processing scheme that has got its own
problems :-(

Create a script to handle stamping release version numbers into files,
replacing the tedious and error-prone manual process we've been using.

Fix datetime input functions to correctly detect integer overflow when
running on a 64-bit platform ... strtol() will happily return 64-bit
output in that case.  Per bug #4231 from Geoff Tolley.

tag 8.0.17

Stamp 8.0.17 (except for configure.in/configure)

Update release notes for 8.3.3 et al.

Fix pg_get_ruledef() so that negative numeric constants are parenthesized.
This is needed because :: casting binds more tightly than minus, so for
example -1::integer is not the same as (-1)::integer, and there are cases
where the difference is important.  In particular this caused a failure
in SELECT DISTINCT ... ORDER BY ... where expressions that should have
matched were seen as different by the parser; but I suspect that there
could be other cases where failure to parenthesize leads to subtler
semantic differences in reloaded rules.  Per report from Alexandr Popov.

Remove link that pre-8.2 doc tools don't support.

tag 8.0.16

Stamp 8.0.16 (except for configure.in/configure)

Translation updates.

Draft release notes for upcoming back-branch updates.

Update time zone data files to tzdata release 2008c (DST law changes in
Morocco, Iraq, Choibalsan, Pakistan, Syria, Cuba, Argentina/San_Luis).

Improve GRANT documentation to point out that UPDATE and DELETE typically
require SELECT privilege as well, since you normally need to read existing
column values within such commands.  This behavior is according to spec,
but we'd never documented it before.  Per gripe from Volkan Yazici.

Back-patch the 8.3 fix that prohibits TRUNCATE, CLUSTER, and REINDEX when the
current transaction has any open references to the target relation or index
(implying it has an active query using the relation).  Also back-patch the
8.2 fix that prohibits TRUNCATE and CLUSTER when there are pending
AFTER-trigger events.  Per suggestion from Heikki.

Fix an old corner-case bug in set_config_option: push_old_value has to be
called before, not after, calling the assign_hook if any.  This is because
push_old_value might fail (due to palloc out-of-memory), and in that case
there would be no stack entry to tell transaction abort to undo the GUC
assignment.  Of course the actual assignment to the GUC variable hasn't
happened yet --- but the assign_hook might have altered subsidiary state.
Without a stack entry we won't call it again to make it undo such actions.
So this is necessary to make the world safe for assign_hooks with side
effects.  Per a discussion a couple weeks ago with Magnus.

Back-patch to 8.0.  7.x did not have the problem because it did not have
allocatable stacks of GUC values.

Adjust timestamp regression tests to prevent two low-probability failure
cases.  Recent buildfarm experience shows that it is sometimes possible
to execute several SQL commands in less time than the granularity of
Windows' not-very-high-resolution gettimeofday(), leading to a failure
because the tests expect the value of now() to change and it doesn't.
Also, it was recognized some time ago that the same area of the tests
could fail if local midnight passes between the insertion and the checking
of the values for 'yesterday', 'tomorrow', etc.  Clean all this up per
ideas from myself and Greg Stark.

There remains a window for failure if the transaction block is entered
exactly at local midnight (so that 'now' and 'today' have the same value),
but that seems low-probability enough to live with.

Since the point of this change is mostly to eliminate buildfarm noise,
back-patch to all versions we are still actively testing.

Don't try to close negative file descriptors, since this can cause
crashes on certain platforms. In particular, the MSVC runtime is known
to do this.

Fixes bug #4162, reported and diagnosed by Javier Pimas

Fix an ancient oversight in change_varattnos_of_a_node: it neglected to update
varoattno along with varattno.  This resulted in having Vars that were not
seen as equal(), causing inheritance of the "same" constraint from different
parent relations to fail.  An example is

create table pp1 (f1 int check (f1>0));
create table cc1 (f2 text, f3 int) inherits (pp1);
create table cc2(f4 float) inherits(pp1,cc1);

Backpatch as far as 7.4.  (The test case still fails in 7.4, for reasons
that I don't feel like investigating at the moment.)

This is a backpatch commit only.  The fix will be applied in HEAD as part
of the upcoming pg_constraint patch.

Fix contrib/xml makefile to not override CFLAGS.

Fix contrib/xml2 makefile to not override CFLAGS.

Fix ALTER TABLE ADD COLUMN ... PRIMARY KEY so that the new column is correctly
checked to see if it's been initialized to all non-nulls.  The implicit NOT
NULL constraint was not being checked during the ALTER (in fact, not even if
there was an explicit NOT NULL too), because ATExecAddColumn neglected to
set the flag needed to make the test happen.  This has been broken since
the capability was first added, in 8.0.

Brendan Jurd, per a report from Kaloyan Iliev.

Replace developer FAQ with a reference to the wiki, which is where
it now lives (per discussion). Leave the other FAQs alone for now.

Add link to major version release notes at the top of the minor
version ones, to make it clear to users just browsing the notes
that there are a lot more changes available from whatever version
they are at than what's in the minor version release notes.

Fix several datatype input functions that were allowing unused bytes in their
results to contain uninitialized, unpredictable values.  While this was okay
as far as the datatypes themselves were concerned, it's a problem for the
parser because occurrences of the "same" literal might not be recognized as
equal by datumIsEqual (and hence not by equal()).  It seems sufficient to fix
this in the input functions since the only critical use of equal() is in the
parser's comparisons of ORDER BY and DISTINCT expressions.
Per a trouble report from Marc Cousin.

Patch all the way back.  Interestingly, array_in did not have the bug before
8.2, which may explain why the issue went unnoticed for so long.

Fixed bug in PGTYPEStimestamp_sub that used pointers instead of the values to substract.

Defend against JOINs having more than 32K columns altogether.  We cannot
currently support this because we must be able to build Vars referencing
join columns, and varattno is only 16 bits wide.  Perhaps this should be
improved in future, but considering that it never came up before, I'm not
sure the problem is worth much effort.  Per bug #4070 from Marcello
Ceschia.

The problem seems largely academic in 8.0 and 7.4, because they have
(different) O(N^2) performance issues with such wide joins, but
back-patch all the way anyway.

Fix a number of places that were making file-type tests infelicitously.
The places that did, eg,
(statbuf.st_mode & S_IFMT) == S_IFDIR
were correct, but there is no good reason not to use S_ISDIR() instead,
especially when that's what the other 90% of our code does.  The places
that did, eg,
(statbuf.st_mode & S_IFDIR)
were flat out *wrong* and would fail in various platform-specific ways,
eg a symlink could be mistaken for a regular file on most Unixen.

The actual impact of this is probably small, since the problem cases
seem to always involve symlinks or sockets, which are unlikely to be
found in the directories that PG code might be scanning.  But it's
clearly trouble waiting to happen, so patch all the way back anyway.
(There seem to be no occurrences of the mistake in 7.4.)

Fix core dump in contrib/xml2's xpath_table() when the input query returns
a NULL value.  Per bug #4058.

Adjust DatumGetBool macro so that it isn't fooled by garbage in the Datum
to the left of the actual bool value.  While in most cases there won't be
any, our support for old-style user-defined functions violates the C spec
to the extent of calling functions that might return char or short through
a function pointer declared to return "char *", which we then coerce to
Datum.  It is not surprising that the result might contain garbage
high-order bits ... what is surprising is that we didn't see such cases
long ago.  Per report from Magnus.

This is a back-patch of a change that was made in HEAD almost exactly
a year ago.  I had refrained from back-patching at the time, but now
we find that this is *necessary* for contrib to work with gcc 4.3.

Add the missing cyrillic "Yo" characters ('e' and 'E' with two dots) to the
ISO_8859-5 <-> MULE_INTERNAL conversion tables.

This was discovered when trying to convert a string containing those characters
from ISO_8859-5 to Windows-1251, because we use MULE_INTERNAL/KOI8R as an
intermediate encoding between those two.

While the missing "Yo" was just an omission in the conversion tables, there are
a few other characters like the "Numero" sign ("No" as a single character) that
exists in all the other cyrillic encodings (win1251, ISO_8859-5 and cp866), but
not in KOI8R. Added comments about that.

Patch by Sergey Burladyan. Back-patch to 7.4.

Fix regexp substring matching (substring(string from pattern)) for the corner
case where there is a match to the pattern overall but the user has specified
a parenthesized subexpression and that subexpression hasn't got a match.
An example is substring('foo' from 'foo(bar)?').  This should return NULL,
since (bar) isn't matched, but it was mistakenly returning the whole-pattern
match instead (ie, 'foo').  Per bug #4044 from Rui Martins.

This has been broken since the beginning; patch in all supported versions.
The old behavior was sufficiently inconsistent that it's impossible to believe
anyone is depending on it.