Check for gcov and lcov only when coverage testing is enabled.

Add some additional casts and regression tests for the citext data type.
David Wheeler

Add Win32 MSVC code to support this recent patch:

Add missing descriptions for aggregates, functions and conversions.

Bernd Helmle

Code coverage testing with gcov.  Documentation is in the regression test
chapter.

Author: Michelle Caisse <Michelle.Caisse@Sun.COM>

Add DSSSL stylesheet location for Mac OS X/Fink installation.

Fix strategy propagation to scanEntry for partial match by moving propagation
to initializaion of scanEntry.

If a loadable module has wrong values in its magic block, spell out
exactly what they are in the complaint message.  Marko Kreen,
some editorialization by me.

Prevent memory leaks in our various bison parsers when an error occurs
during parsing.  Formerly the parser's stack was allocated with malloc
and so wouldn't be reclaimed; this patch makes it use palloc instead,
so that flushing the current context will reclaim the memory.  Per
Marko Kreen.

Fix plpgsql's exec_move_row() to supply valid type OIDs to exec_assign_value()
whenever possible, as per bug report from Oleg Serov.  While at it, reorder
the operations in the RECORD case to avoid possible palloc failure while the
variable update is only partly complete.

Back-patch as far as 8.1.  Although the code of the particular function is
similar in 8.0, 8.0's support for composite fields in rows is sufficiently
broken elsewhere that it doesn't seem worth fixing this.

Sigh, I missed checking the ecpg tests ...

Add a variant expected-output file for the sequence regression test, to cover
output that is seen when a checkpoint occurs at just the right time during
the test.  Per my report of 2008-08-31.

This could be back-patched but I'm not sure it's worth the trouble.

Add a bunch of new error location reports to parse-analysis error messages.
There are still some weak spots around JOIN USING and relation alias lists,
but most errors reported within backend/parser/ now have locations.

HeapTupleHeaderAdjustCmax made the incorrect assumption that the raw
command id is the cmin, when it can in fact be a combo cid. That made rows
incorrectly invisible to a transaction where a tuple was deleted by multiple
aborted subtransactions.

Report and patch Karl Schnaitter. Back-patch to 8.3, where combo cids was
introduced.

Synchronize the shared object build rules in Makefile.port with Makefile.shlib
somewhat by adding CFLAGS where the compiler is used and Makefile.shlib
already used CFLAGS.

Fix (hopefully) some oversights in recent Bison cleanup patch.
Per buildfarm results.

Fix the raw-parsetree representation of star (as in SELECT * FROM or
SELECT foo.*) so that it cannot be confused with a quoted identifier "*".
Instead create a separate node type A_Star to represent this notation.
Per pgsql-hackers discussion of 2007-Sep-27.

In GCC-based builds, use a better newNode() macro that relies on GCC-specific
syntax to avoid a useless store into a global variable.  Per experimentation,
this works better than my original thought of trying to push the code into
an out-of-line subroutine.

Fixup pg_dumpall adding --lock-wait-timeout, to match pg_dump.

David Gould

Suppress gcc warning about possibly-uninitialized variable.  It's not
clear to me why I'd not seen this message before --- on F-9 it seems to
only happen if Asserts are disabled, which ought to be irrelevant.
Maybe that affects a decision whether to inline get_ten(), which would
be needed to expose the warning condition to the compiler?  Anyway,
the fix is clear.

Document that \t and \x are now settable.

Remove all traces that suggest that a non-Bison yacc might be supported, and
change build system to use only Bison.  Simplify build rules, make file names
uniform.  Don't build the token table header file where it is not needed.

Extend the parser location infrastructure to include a location field in
most node types used in expression trees (both before and after parse
analysis).  This allows us to place an error cursor in many situations
where we formerly could not, because the information wasn't available
beyond the very first level of parse analysis.  There's a fair amount
of work still to be done to persuade individual ereport() calls to actually
include an error location, but this gets the initdb-forcing part of the
work out of the way; and the situation is already markedly better than
before for complaints about unimplementable implicit casts, such as
CASE and UNION constructs with incompatible alternative data types.
Per my proposal of a few days ago.

Teach eval_const_expressions() to simplify an ArrayCoerceExpr to a constant
when its input is constant and the element coercion function is immutable
(or nonexistent, ie, binary-coercible case).  This is an oversight in the
8.3 implementation of ArrayCoerceExpr, and its result is that certain cases
involving IN or NOT IN with constants don't get optimized as they should be.
Per experimentation with an example from Ow Mun Heng.

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

Add %option noinput to contrib's flex scanners, to suppress gcc 4.3
warnings.  Peter did this for core awhile ago but evidently missed
contrib.

Move exprType(), exprTypmod(), expression_tree_walker(), and related routines
into nodes/nodeFuncs, so as to reduce wanton cross-subsystem #includes inside
the backend.  There's probably more that should be done along this line,
but this is a start anyway.

Get rid of the last remaining uses of var_is_rel(), to wit some debugging
checks in ExecIndexBuildScanKeys() that were inadequate anyway: it's better
to verify the correct varno on an expected index key, not just reject OUTER
and INNER.

This makes the entire current contents of nodeFuncs.c dead code.  I'll be
replacing it with some other stuff later, as per recent proposal.

Add standard boilerplate sentence about when stats_temp_directory can be changed.

Unconditionally write the statsfile when SIGHUP is received, to minimize
the window during which backends have no statistics file to read.

Update URL to Ross William's paper.

Devrim Gunduz.

Have man page generation work on VPATH builds too.

Make stats_temp_directory PGC_SIGHUP, and document how it may cause a temporary
"outage" of the statistics views.

This requires making the stats collector respond to SIGHUP, like the other
utility processes already did.

Convert remaining builtin set-returning functions to use OUT parameters, making
it possible to call them without specifying a column list.

Jaime Casanova

Add missing descriptions for aggregates, functions and conversions.

Bernd Helmle

Fix possible duplicate tuples while  GiST scan. Now page is processed
at once and ItemPointers are collected in memory.

Remove tuple's killing by killtuple() if tuple was moved to another
page - it could produce unaceptable overhead.

Backpatch up to 8.1 because the bug was introduced by GiST's concurrency support.

Update link to developer's FAQ from main FAQ.

Make "log_temp_files" super-user set only, like other logging options.

Simon Riggs

Minor patch on pgbench

1. -i option should run vacuum analyze only on pgbench tables, not *all*
tables in database.

2. pre-run cleanup step was DELETE FROM HISTORY then VACUUM HISTORY.
This is just a slow version of TRUNCATE HISTORY.

Simon Riggs

Improve wording of error message when a postgresql.conf setting is
ignored because it can only be set at server start.

Arrange to convert EXISTS subqueries that are equivalent to hashable IN
subqueries into the same thing you'd have gotten from IN (except always with
unknownEqFalse = true, so as to get the proper semantics for an EXISTS).
I believe this fixes the last case within CVS HEAD in which an EXISTS could
give worse performance than an equivalent IN subquery.

The tricky part of this is that if the upper query probes the EXISTS for only
a few rows, the hashing implementation can actually be worse than the default,
and therefore we need to make a cost-based decision about which way to use.
But at the time when the planner generates plans for subqueries, it doesn't
really know how many times the subquery will be executed.  The least invasive
solution seems to be to generate both plans and postpone the choice until
execution.  Therefore, in a query that has been optimized this way, EXPLAIN
will show two subplans for the EXISTS, of which only one will actually get
executed.

There is a lot more that could be done based on this infrastructure: in
particular it's interesting to consider switching to the hash plan if we start
out using the non-hashed plan but find a lot more upper rows going by than we
expected.  I have therefore left some minor inefficiencies in place, such as
initializing both subplans even though we will currently only use one.

Mention that pg_dump does not dump ALTER DATABASE ... SET commands;
backpatch to 8.3.X. Also fix markup that had just one bullet.

Update URL.

Autoconf 2.62 will require cache variables to contain "_cv_".  Fix our few
noncomplying cases to be future-proof.

Marginal improvement in sublink planning: allow unknownEqFalse optimization
to be used for SubLinks that are underneath a top-level OR clause.  Just as at
the very top level of WHERE, it's not necessary to be accurate about whether
the sublink returns FALSE or NULL, because either result has the same impact
on whether the WHERE will succeed.

Remove tools and documention for generating TODO.html.

TODO now in wiki, html version removed.

New TODO list URL wiki location listed; contents truncated.

Fix obsolete comment.  It's no longer the case that Param nodes don't
carry typmod.

Synced parser.

Make libpq on windows not try to send chunks larger than 64Kb.

Per Microsoft knowledge base article Q201213, early versions of
Windows fail when we do this. Later versions of Windows appear
to have a higher limit than 64Kb, but do still fail on large
sends, so we unconditionally limit it for all versions.

Patch from Tom Lane.

Not done:

<  o -Allow an existing index to be marked as a table's primary key
>  o Allow an existing index to be marked as a table's primary key

Remove -Winline from the default set of CFLAGS for gcc.  It's gotten much
too noisy to be useful as of gcc 4.3, and we were never really doing
anything about inlining warnings anyway.

Cause the output from debug_print_parse, debug_print_rewritten, and
debug_print_plan to appear at LOG message level, not DEBUG1 as historically.
Make debug_pretty_print default to on.  Also, cause plans generated via
EXPLAIN to be subject to debug_print_plan.  This is all to make
debug_print_plan a reasonably comfortable substitute for the former behavior
of EXPLAIN VERBOSE.

TODO done:

!       o Allow an existing index to be marked as a table's primary key

Fixed incorrect argument handling in SET command if argument is a variable.

Fix some issues that prevent this file to be processed by scripts.

While at it, mark a couple of items completed in 8.4:
!   o -Prevent long-lived temporary tables from causing frozen-xid
      advancement starvation

! * -Improve performance of shared invalidation queue for multiple CPUs

Also remove a couple of obsolete assignments.

Add to TODO:

>
> * Fix all set-returning system functions so they support a wildcard
>   target list
>
>   SELECT * FROM pg_get_keywords() works but SELECT * FROM
>   pg_show_all_settings() does not.

Properly remove src\include\utils\probes.h when running clean.bat.

Add some defenses against constant-FALSE outer join conditions.  Since
eval_const_expressions will generally throw away anything that's ANDed with
constant FALSE, what we're left with given an example like

select * from tenk1 a where (unique1,0) in (select unique2,1 from tenk1 b);

is a cartesian product computation, which is really not acceptable.
This is a regression in CVS HEAD compared to previous releases, which were
able to notice the impossible join condition in this case --- though not in
some related cases that are also improved by this patch, such as

select * from tenk1 a left join tenk1 b on (a.unique1=b.unique2 and 0=1);

Fix by skipping evaluation of the appropriate side of the outer join in
cases where it's demonstrably unnecessary.

Remove prohibition against SubLinks in the WHERE clause of an EXISTS subquery
that we're considering pulling up.  I hadn't wanted to think through whether
that could work during the first pass at this stuff.  However, on closer
inspection it seems to be safe enough.

Improve sublink pullup code to handle ANY/EXISTS sublinks that are at top
level of a JOIN/ON clause, not only at top level of WHERE.  (However, we
can't do this in an outer join's ON clause, unless the ANY/EXISTS refers
only to the nullable side of the outer join, so that it can effectively
be pushed down into the nullable side.)  Per request from Kevin Grittner.

In passing, fix a bug in the initial implementation of EXISTS pullup:
it would Assert if the EXIST's WHERE clause used a join alias variable.
Since we haven't yet flattened join aliases when this transformation
happens, it's necessary to include join relids in the computed set of
RHS relids.

Update instructions on generating TODO.html.

probes.h is generated from probes.d, not pg_trace.d.

Add URL for:

* Improve ability to modify views via ALTER TABLE
<
>   http://archives.postgresql.org/pgsql-hackers/2008-08/msg00300.php

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.

Add to TODO:

>
> * Prevent query cancel packets from being replayed by an attacker,
>   especially when using SSL
>
>   http://archives.postgresql.org/pgsql-hackers/2008-08/msg00345.php
>

Synchronize Borland libpq makefile to match MSVC.  Backpatch to 8.3.X.

Fix a couple of places where psql might fail to report a suitable error
if PQexec returns NULL.  These don't seem significant enough to be worth
back-patching, but they ought to get fixed ...

Update Russian FAQ.

corochoone@gmail.com

Add new SQL training web site to FAQ:

    <LI><A href=
    "http://sqlzoo.net">http://sqlzoo.net</A>
    </LI>

Fix version warning bug in recently applied adjustments to psql startup.

Gregory Stark

Clean up the loose ends in selectivity estimation left by my patch for semi
and anti joins.  To do this, pass the SpecialJoinInfo struct for the current
join as an additional optional argument to operator join selectivity
estimation functions.  This allows the estimator to tell not only what kind
of join is being formed, but which variable is on which side of the join;
a requirement long recognized but not dealt with till now.  This also leaves
the door open for future improvements in the estimators, such as accounting
for the null-insertion effects of lower outer joins.  I didn't do anything
about that in the current patch but the information is in principle deducible
from what's passed.

The patch also clarifies the definition of join selectivity for semi/anti
joins: it's the fraction of the left input that has (at least one) match
in the right input.  This allows getting rid of some very fuzzy thinking
that I had committed in the original 7.4-era IN-optimization patch.
There's probably room to estimate this better than the present patch does,
but at least we know what to estimate.

Since I had to touch CREATE OPERATOR anyway to allow a variant signature
for join estimator functions, I took the opportunity to add a couple of
additional checks that were missing, per my recent message to -hackers:
* Check that estimator functions return float8;
* Require execute permission at the time of CREATE OPERATOR on the
operator's function as well as the estimator functions;
* Require ownership of any pre-existing operator that's modified by
the command.
I also moved the lookup of the functions out of OperatorCreate() and
into operatorcmds.c, since that seemed more consistent with most of
the other catalog object creation processes, eg CREATE TYPE.

Performance fix for new anti-join code in nodeMergejoin.c: after finding a
match in antijoin mode, we should advance to next outer tuple not next inner.
We know we don't want to return this outer tuple, and there is no point in
advancing over matching inner tuples now, because we'd just have to do it
again if the next outer tuple has the same merge key.  This makes a noticeable
difference if there are lots of duplicate keys in both inputs.

Similarly, after finding a match in semijoin mode, arrange to advance to
the next outer tuple after returning the current match; or immediately,
if it fails the extra quals.  The rationale is the same.  (This is a
performance bug in existing releases; perhaps worth back-patching?  The
planner tries to avoid using mergejoin with lots of duplicates, so it may
not be a big issue in practice.)

Nestloop and hash got this right to start with, but I made some cosmetic
adjustments there to make the corresponding bits of logic look more similar.

Make the temporary directory for pgstat files configurable by the GUC
variable stats_temp_directory, instead of requiring the admin to
mount/symlink the pg_stat_tmp directory manually.

For now the config variable is PGC_POSTMASTER. Room for further improvment
that would allow it to be changed on-the-fly.

Fix pull_up_simple_union_all to copy all rtable entries from child subquery to
parent, not only those with RangeTblRefs. We need them in ExecCheckRTPerms.

Report by Brendan O'Shea. Back-patch to 8.2, where pull_up_simple_union_all
was introduced.

Implement SEMI and ANTI joins in the planner and executor.  (Semijoins replace
the old JOIN_IN code, but antijoins are new functionality.)  Teach the planner
to convert appropriate EXISTS and NOT EXISTS subqueries into semi and anti
joins respectively.  Also, LEFT JOINs with suitable upper-level IS NULL
filters are recognized as being anti joins.  Unify the InClauseInfo and
OuterJoinInfo infrastructure into "SpecialJoinInfo".  With that change,
it becomes possible to associate a SpecialJoinInfo with every join attempt,
which permits some cleanup of join selectivity estimation.  That needs to be
taken much further than this patch does, but the next step is to change the
API for oprjoin selectivity functions, which seems like material for a
separate patch.  So for the moment the output size estimates for semi and
especially anti joins are quite bogus.

pg_buffercache needs to be taught about relation forks, as Greg Stark
pointed out.

Add URL for:

* Improve ability to modify views via ALTER TABLE

>   http://archives.postgresql.org/pgsql-hackers/2008-07/msg01410.php

Have autovacuum consider processing TOAST tables separately from their
main tables.

This requires vacuum() to accept processing a toast table standalone, so
there's a user-visible change in that it's now possible (for a superuser) to
execute "VACUUM pg_toast.pg_toast_XXX".

Remove TODO item

    Allow XML to accept more liberal DOCTYPE specifications

Everything works correctly, per today's email to -general.

Add:

> * Add 'hostgss' pg_hba.conf option to allow GSS link-level encryption
>
>   http://archives.postgresql.org/pgsql-hackers/2008-07/msg01454.php

Relation forks patch requires a catversion bump due to changes in the format
of some WAL records, and two-phase state files, which I forgot.

Introduce the concept of relation forks. An smgr relation can now consist
of multiple forks, and each fork can be created and grown separately.

The bulk of this patch is about changing the smgr API to include an extra
ForkNumber argument in every smgr function. Also, smgrscheduleunlink and
smgrdounlink no longer implicitly call smgrclose, because other forks might
still exist after unlinking one. The callers of those functions have been
modified to call smgrclose instead.

This patch in itself doesn't have any user-visible effect, but provides the
infrastructure needed for upcoming patches. The additional forks envisioned
are a rewritten FSM implementation that doesn't rely on a fixed-size shared
memory block, and a visibility map to allow skipping portions of a table in
VACUUM that have no dead tuples.

Fix corner-case bug introduced with HOT: if REINDEX TABLE pg_class (or a
REINDEX DATABASE including same) is done before a session has done any other
update on pg_class, the pg_class relcache entry was left with an incorrect
setting of rd_indexattr, because the indexed-attributes set would be first
demanded at a time when we'd forced a partial list of indexes into the
pg_class entry, and it would remain cached after that.  This could result
in incorrect decisions about HOT-update safety later in the same session.
In practice, since only pg_class_relname_nsp_index would be missed out,
only ALTER TABLE RENAME and ALTER TABLE SET SCHEMA could trigger a problem.
Per report and test case from Ondrej Jirman.

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.

Improve INTERSECT/EXCEPT hashing by realizing that we don't need to make any
hashtable entries for tuples that are found only in the second input: they
can never contribute to the output.  Furthermore, this implies that the
planner should endeavor to put first the smaller (in number of groups) input
relation for an INTERSECT.  Implement that, and upgrade prepunion's estimation
of the number of rows returned by setops so that there's some amount of sanity
in the estimate of which one is smaller.

Support hashing for duplicate-elimination in INTERSECT and EXCEPT queries.
This completes my project of improving usage of hashing for duplicate
elimination (aggregate functions with DISTINCT remain undone, but that's
for some other day).

As with the previous patches, this means we can INTERSECT/EXCEPT on datatypes
that can hash but not sort, and it means that INTERSECT/EXCEPT without ORDER
BY are no longer certain to produce sorted output.

Teach the system how to use hashing for UNION.  (INTERSECT/EXCEPT will follow,
but seem like a separate patch since most of the remaining work is on the
executor side.)  I took the opportunity to push selection of the grouping
operators for set operations into the parser where it belongs.  Otherwise this
is just a small exercise in making prepunion.c consider both alternatives.

As with the recent DISTINCT patch, this means we can UNION on datatypes that
can hash but not sort, and it means that UNION without ORDER BY is no longer
certain to produce sorted output.

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.

Department of second thoughts: fix newly-added code in planner.c to make real
sure that DISTINCT ON does what it's supposed to, ie, sort by the full ORDER
BY list before unique-ifying.  The error seems masked in simple cases by the
fact that query_planner won't return query pathkeys that only partially match
the requested sort order, but I wouldn't want to bet that it couldn't be
exposed in some way or other.

Add an ORDER BY to one more SELECT DISTINCT test case, per buildfarm results.

In ReadOrZeroBuffer (and related entry points), don't bother to call
PageHeaderIsValid when we zero the buffer instead of reading the page in.
The actual performance improvement is probably marginal since this function
isn't very heavily used, but a cycle saved is a cycle earned.

Zdenek Kotala

Move pgstat.tmp into a temporary directory under $PGDATA named pg_stat_tmp.
This allows the use of a ramdrive (either through mount or symlink) for
the temporary file that's written every half second, which should
reduce I/O.

On server shutdown/startup, the file is written to the old location in
the global directory, to preserve data across restarts.

Bump catversion since the $PGDATA directory layout changed.

Fix some message style guideline violations in pg_regress, as well as
some failures to expose messages for translation.

Improve SELECT DISTINCT to consider hash aggregation, as well as sort/uniq,
as methods for implementing the DISTINCT step.  This eliminates the former
performance gap between DISTINCT and GROUP BY, and also makes it possible
to do SELECT DISTINCT on datatypes that only support hashing not sorting.

SELECT DISTINCT ON is still always implemented by sorting; it would take
executor changes to support hashing that, and it's not clear it's worth
the trouble.

This is a release-note-worthy incompatibility from previous PG versions,
since SELECT DISTINCT can no longer be counted on to deliver sorted output
without explicitly saying ORDER BY.  (Anyone who can't cope with that
can consider turning off enable_hashagg.)

Several regression test queries needed to have ORDER BY added to preserve
stable output order.  I fixed the ones that manifested here, but there
might be some other cases that show up on other platforms.

Improve CREATE/DROP/RENAME DATABASE so that when failing because the source
or target database is being accessed by other users, it tells you whether
the "other users" are live sessions or uncommitted prepared transactions.
(Indeed, it tells you exactly how many of each, but that's mostly just
because it was easy to do so.)  This should help forestall the gotcha of
not realizing that a prepared transaction is what's blocking the command.
Per discussion.

Make GROUP BY work properly for datatypes that only support hashing and not
sorting.  The infrastructure for this was all in place already; it's only
necessary to fix the planner to not assume that sorting is always an available
option.

Tighten up the sanity checks in TypeCreate(): pass-by-value types must have
a size that is one of the supported values, not just anything <= sizeof(Datum).
Cross-check the alignment specification against size as well.

Fix copy-and-pasteo that's causing pg_regress to lie about which file it can't
read when the --temp-config argument is bad.  Noted while wondering why
buildfarm member dungbeetle is failing ... this isn't why, but it is why
the error report isn't very helpful ...

Rearrange the querytree representation of ORDER BY/GROUP BY/DISTINCT items
as per my recent proposal:

1. Fold SortClause and GroupClause into a single node type SortGroupClause.
We were already relying on them to be struct-equivalent, so using two node
tags wasn't accomplishing much except to get in the way of comparing items
with equal().

2. Add an "eqop" field to SortGroupClause to carry the associated equality
operator.  This is cheap for the parser to get at the same time it's looking
up the sort operator, and storing it eliminates the need for repeated
not-so-cheap lookups during planning.  In future this will also let us
represent GROUP/DISTINCT operations on datatypes that have hash opclasses
but no btree opclasses (ie, they have equality but no natural sort order).
The previous representation simply didn't work for that, since its only
indicator of comparison semantics was a sort operator.

3. Add a hasDistinctOn boolean to struct Query to explicitly record whether
the distinctClause came from DISTINCT or DISTINCT ON.  This allows removing
some complicated and not 100% bulletproof code that attempted to figure
that out from the distinctClause alone.

This patch doesn't in itself create any new capability, but it's necessary
infrastructure for future attempts to use hash-based grouping for DISTINCT
and UNION/INTERSECT/EXCEPT.