First, genericcostestimate() was being way too liberal about including
partial-index conditions in its selectivity estimate, resulting in
substantial underestimates for situations such as an indexqual "x = 42"
used with an index on x "WHERE x >= 40 AND x < 50".  While the code is
intentionally set up to favor selecting partial indexes when available,
this was too much...

Second, choose_bitmap_and() was likewise easily fooled by cases of this
type, since it would similarly think that the partial index had selectivity
independent of the indexqual.

Fixed by using predicate_implied_by() rather than simple equality checks
to determine redundancy.  This is a good deal more expensive but I don't
see much alternative.  At least the extra cost is only paid when there's
actually a partial index under consideration.

Per report from Jeff Davis.  I'm not going to risk back-patching this,
though.

<
<
> 	o During index creation, pre-sort the tuples to improve build speed
>
> 	  http://archives.postgresql.org/pgsql-hackers/2007-03/msg01199.php
>

< * Add NUMERIC division operator that doesn't round?
<
<   Currently NUMERIC _rounds_ the result to the specified precision.
<   This means division can return a result that multiplied by the
<   divisor is greater than the dividend, e.g. this returns a value > 10:
<
<     SELECT (10::numeric(2,0) / 6::numeric(2,0))::numeric(2,0) * 6;
<
<   The positive modulus result returned by NUMERICs might be considered
<   inaccurate, in one sense.
<

* Add locale-aware MONEY type, and support multiple currencies
  http://archives.postgresql.org/pgsql-hackers/2007-03/msg01181.php

Uses same underlying tech as before, but not the sysv emulation layer.

* Allow accurate statistics to be collected on indexes with more than
  one column or expression indexes, perhaps using per-index statistics
>   http://archives.postgresql.org/pgsql-hackers/2007-03/msg01131.php

< 	o -Allow commenting of variables in postgresql.conf to restore them
> 	o Allow commenting of variables in postgresql.conf to restore them

> 	o -Allow commenting of variables in postgresql.conf to restore them
< 	  http://archives.postgresql.org/pgsql-hackers/2006-09/msg01481.php

and regexp_split_to_table. These functions provide access to the
capture groups resulting from a POSIX regular expression match,
and provide the ability to split a string on a POSIX regular
expression, respectively. Patch from Jeremy Drake; code review by
Neil Conway, additional comments and suggestions from Tom and
Peter E.

This patch bumps the catversion, adds some regression tests,
and updates the docs.

BTW, the comment in this file says that we hope we never have more than
10 catversion changes per day, but to even make this possible we should
start counting at zero, shouldn't we?


Jan

rules to be defined with different, per session controllable, behaviors
for replication purposes.

This will allow replication systems like Slony-I and, as has been stated
on pgsql-hackers, other products to control the firing mechanism of
triggers and rewrite rules without modifying the system catalog directly.

The firing mechanisms are controlled by a new superuser-only GUC
variable, session_replication_role, together with a change to
pg_trigger.tgenabled and a new column pg_rewrite.ev_enabled. Both
columns are a single char data type now (tgenabled was a bool before).
The possible values in these attributes are:

     'O' - Trigger/Rule fires when session_replication_role is "origin"
           (default) or "local". This is the default behavior.

     'D' - Trigger/Rule is disabled and fires never

     'A' - Trigger/Rule fires always regardless of the setting of
           session_replication_role

     'R' - Trigger/Rule fires when session_replication_role is "replica"

The GUC variable can only be changed as long as the system does not have
any cached query plans. This will prevent changing the session role and
accidentally executing stored procedures or functions that have plans
cached that expand to the wrong query set due to differences in the rule
firing semantics.

The SQL syntax for changing a triggers/rules firing semantics is

     ALTER TABLE <tabname> <when> TRIGGER|RULE <name>;

     <when> ::= ENABLE | ENABLE ALWAYS | ENABLE REPLICA | DISABLE

psql's \d command as well as pg_dump are extended in a backward
compatible fashion.

Jan

"If the patch is not BSD-licensed, it will be rejected."

test in parallel with the rules test at all, because the former wants to
create a couple of temp views, which can sometimes show up in the latter's
output.  Let's try it in the next parallel group instead.

to cover it.  Per report from Anton Pikhteryev.

* Simplify ability to create partitioned tables
>   http://archives.postgresql.org/pgsql-hackers/2007-03/msg00375.php

* Allow sequential scans to take advantage of other concurrent
  sequential scans, also called "Synchronised Scanning"

  http://archives.postgresql.org/pgsql-hackers/2007-03/msg00415.php

on preproc.h, else make may try to build it before preproc.h is ready.
Per failures seen here and in buildfarm.

are initialized with a string literal. Patch from Stefan Huehner.

to ANSI-style, and change "()" -> "(void)". Patch from Stefan Huehner.

- Made some chars const as proposed by Stefan Huehner <stefan@huehner.org>.
- Synced parser and keyword lists.
- Copied two token parsing from backend parser to ecpg parser.
- Also added a test case for this.

what each script does.

skeleton scripts calling them. To make it easier for the buildfarm
(or other "outside callers") to use these modules directly.

Per suggestion from Andrew Dunstan.

executed in read_only mode.  This could lead to various relatively-subtle
failures, such as an allegedly stable function returning non-stable results.
Bug goes all the way back to the introduction of read-only mode in 8.0.
Per report from Gaetano Mendola.

cut at exprTypmod support.  Also, experimentation shows that we need
to label the type of Const nodes that are numeric with a specific
typmod.

available information about the typmod of an expression; namely, Const,
ArrayRef, ArrayExpr, and EXPR and ARRAY SubLinks.  In the ArrayExpr and
SubLink cases it wasn't really the data structure's fault, but exprTypmod()
being lazy.  This seems like a good idea in view of the expected increase in
typmod usage from Teodor's work to allow user-defined types to have typmods.
In particular this responds to the concerns we had about eliminating the
special-purpose hack that exprTypmod() used to have for BPCHAR Consts.
We can now tell whether or not such a Const has been cast to a specific
length, and report or display properly if so.

initdb forced due to changes in stored rules.

pg_stat_database.

was expecting there to be no regular table named 'foo', but it turns out
the rules test transiently creates one, so that plancache would sometimes
fail.  I couldn't reproduce that in quite a few tries here, but several
buildfarm machines have shown the failure.  Fix by renaming plancache's
temp table to something nonconflicting.

reported in some cases.  Report and patch from Tatsuhito Kasahara.

Also fix a couple of other bugs I noticed in skimming the surrounding code.

Remove undocumented support for copy syntax from before 7.3. Update comments to
reflect syntax actually supported, e.g. by including CSV params.

Greg Sabino Mullane

uses SPI plans, this finally fixes the ancient gotcha that you can't
drop and recreate a temp table used by a plpgsql function.

Along the way, clean up SPI's API a little bit by declaring SPI plan
pointers as "SPIPlanPtr" instead of "void *".  This is cosmetic but
helps to forestall simple programming mistakes.  (I have changed some
but not all of the callers to match; there are still some "void *"'s
in contrib and the PL's.  This is intentional so that we can see if
anyone's compiler complains about it.)