of discovery, rather than reverse order.  This doesn't matter functionally
(I suppose the previous coding dates from the time when lcons was markedly
cheaper than lappend).  However now that EXPLAIN is labeling subplans with
IDs that are based on order of creation, this may help produce a slightly
less surprising printout.

are individually labeled, rather than just grouped under an "InitPlan"
or "SubPlan" heading.  This in turn makes it possible for decompilation of
a subplan reference to usefully identify which subplan it's referencing.
I also made InitPlans identify which parameter symbol(s) they compute,
so that references to those parameters elsewhere in the plan tree can
be connected to the initplan that will be executed.  Per a gripe from
Robert Haas about EXPLAIN output of a WITH query being inadequate,
plus some longstanding pet peeves of my own.

Improve comments. Now GIN-indexable operators should be strict.
Per Tom's questions/suggestions.

are using our own ports of getopt or getopt_long, those will define
the variable for themselves; and if not, we don't need these, because
we never touch the variable anyway.

provides optreset.  Current mastodon results prove that in fact it
does not; it was only because getopt.c defined the variable anyway
that things failed to fall over.

don't cause confusion with the built-in anyarray versions of those operators.
Adjust the module's index opclasses to support the built-in operators in place
of the private ones.

The private implementations are still available under their historical
names @ and ~, so no functionality is lost.  Some quick testing suggests
that they offer no real benefit over the core operators, however.

Per a complaint from Rusty Conover.

probe for opterr (exactly like the one for optreset) and have getopt.c
define the variables only if configure doesn't find them in libc.

of adding optional namespace and action fields to DefElem.  Having three
node types that do essentially the same thing bloats the code and leads
to errors of confusion, such as in yesterday's bug report from Khee Chin.

when we are waiting for old snapshots to go away during a concurrent index
build.  In particular, this rule lets us avoid waiting for
idle-in-transaction sessions.

This logic could be improved further if we had some way to wake up when
the session we are currently waiting for goes idle-in-transaction.  However
that would be a significantly more complex/invasive patch, so it'll have to
wait for some other day.

Simon Riggs, with some improvements by Tom.

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".

To implement this without almost duplicating the reloption table, treat
relopt_kind as a bitmask instead of an integer value.  This decreases the
range of allowed values, but it's not clear that there's need for that much
values anyway.

This patch also makes heap_reloptions explicitly a no-op for relation kinds
other than heap and TOAST tables.

Patch by ITAGAKI Takahiro with minor edits from me.  (In particular I removed
the bit about adding relation kind to an error message, which I intend to
commit separately.)

TOAST tables and indexes; to wit, never show either.  (You can
examine them with plain \d if you're really so inclined.)

Windows without that, but we shouldn't put bad examples where people might
copy them.  Also, reformat slightly to improve the odds that pgindent
won't go nuts on this.

try to protect an already-existing buffer from being evicted.  This was
left as an open issue when the posix_fadvise patch was committed.  I'm
not sure there's any evidence to justify more work in this area, but we
should have some record about it in the source code.

for its arguments.  Also add a regression test, since someone apparently
changed every single plpython test case to use only named parameters; else
we'd have noticed this sooner.

Euler Taveira de Oliveira, per a report from Alvaro

This method will not catch all different ways since the locale
handling in NTFS doesn't provide an easy way to do that, but it
will hopefully solve the most common cases causing startup
problems when the backend is found in the system PATH.

Attempts to fix bug #4694.

ineffective posix_fadvise().

for simple Var targetlist entries all the time, even when there are other
entries that are not simple Vars.  Also, ensure that we prefetch attributes
(with slot_getsomeattrs) for all Vars in the targetlist, even those buried
within expressions.  In combination these changes seem to significantly
reduce the runtime for cases where tlists are mostly but not exclusively
Vars.  Per my proposal of yesterday.

"effective_io_concurrency" on systems without posix_fadvise().

Andrew Gierth

Robert Lor

Per "maosen.zhang" <maosen.zhang@alibaba-inc.com> report.

specified.

Martin Pihlak

conversion functions.  This allows transaction rollback to revert to a
previous client_encoding setting without doing fresh catalog lookups.
I believe that this explains and fixes the recent report of "failed to commit
client_encoding" failures.

This bug is present in 8.3.x, but it doesn't seem prudent to back-patch
the fix, at least not till it's had some time for field testing in HEAD.

In passing, remove SetDefaultClientEncoding(), which was used nowhere.

we failed to assign, even in "can't happen" cases.  Motivated by wondering
what's going on in a recent trouble report where "failed to commit" did
happen.

casting effort whenever the input value was NULL.  However this prevents
application of not-null domain constraints in the cases that use this
function, as illustrated in bug #4741.  Since this function isn't meant
for use in performance-critical paths anyway, this certainly seems like
another case of "premature optimization is the root of all evil".

Back-patch as far as 8.2; older versions made no effort to enforce
domain constraints here anyway.

when there are many blobs and not so many comments.  Tamas Vincze

per-database settings.

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.

at the top of their sections.

temp relations; this is no more expensive than before, now that we have
pg_class.relistemp.  Insert tests into bufmgr.c to prevent attempting
to fetch pages from nonlocal temp relations.  This provides a low-level
defense against bugs-of-omission allowing temp pages to be loaded into shared
buffers, as in the contrib/pgstattuple problem reported by Stuart Bishop.
While at it, tweak a bunch of places to use new relcache tests (instead of
expensive probes into pg_namespace) to detect local or nonlocal temp tables.