noncomplying cases to be future-proof.

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.

carry typmod.

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.

< 	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

too noisy to be useful as of gcc 4.3, and we were never really doing
anything about inlining warnings anyway.

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.

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

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.

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

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.

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.

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.

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

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.

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

if PQexec returns NULL.  These don't seem significant enough to be worth
back-patching, but they ought to get fixed ...

corochoone@gmail.com

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

Gregory Stark

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.

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.

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.

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.

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.

pointed out.

* Improve ability to modify views via ALTER TABLE

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

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

    Allow XML to accept more liberal DOCTYPE specifications

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

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