inherited, per Taiki Yamaguchi.

of caveats in different places, but close together. One called caveats,
one not. That looks like it just led to somebody not reading some
appropriate caveats in the second group of caveats (on -admin).

Simon Riggs

Update find_gt_lt to allow grep parameters to be passed into it.

Stark, additional fixes and editorialization by Neil Conway. Greg's patch
description:

    Some more doc patches for partitioned tables. In particular replace
    the caveat that INCLUDING CONSTRAINTS doesn't exist and replace it
    with documentation of, well, INCLUDING CONSTRAINTS.

    Also, there was an instance of "LIKE WITH DEFAULTS" which is
    actually spelled "LIKE INCLUDING DEFAULTS".

can create or modify rules for the table.  Do setRuleCheckAsUser() while
loading rules into the relcache, rather than when defining a rule.  This
ensures that permission checks for tables referenced in a rule are done with
respect to the current owner of the rule's table, whereas formerly ALTER TABLE
OWNER would fail to update the permission checking for associated rules.
Removal of separate RULE privilege is needed to prevent various scenarios
in which a grantee of RULE privilege could effectively have any privilege
of the table owner.  For backwards compatibility, GRANT/REVOKE RULE is still
accepted, but it doesn't do anything.  Per discussion here:
http://archives.postgresql.org/pgsql-hackers/2006-04/msg01138.php

Open items:

There were a few tangentially related issues that have come up that I think
are TODOs. I'm likely to tackle one or two of these next so I'm interested in
hearing feedback on them as well.

. Constraints currently do not know anything about inheritance. Tom suggested
  adding a coninhcount and conislocal like attributes have to track their
  inheritance status.

. Foreign key constraints currently do not get copied to new children (and
  therefore my code doesn't verify them). I don't think it would be hard to
  add them and treat them like CHECK constraints.

. No constraints at all are copied to tables defined with LIKE. That makes it
  hard to use LIKE to define new partitions. The standard defines LIKE and
  specifically says it does not copy constraints. But the standard already has
  an option called INCLUDING DEFAULTS; we could always define a non-standard
  extension LIKE table INCLUDING CONSTRAINTS that gives the user the option to
  request a copy including constraints.

. Personally, I think the whole attislocal thing is bunk. The decision about
  whether to drop a column from children tables or not is something that
  should be up to the user and trying to DWIM based on whether there was ever
  a local definition or the column was acquired purely through inheritance is
  hardly ever going to match up with user expectations.

. And of course there's the whole unique and primary key constraint issue. I
  think to get any traction at all on this you have a prerequisite of a real
  partitioned table implementation where the system knows what the partition
  key is so it can recognize when it's a leading part of an index key.

Greg Stark

CONNECTION, fix a number of places that were missed (eg pg_dump support),
avoid executing an extra search of pg_database during startup.

compatibility for release 7.2 and earlier.  I have not altered any
mentions of release 7.3 or later.  The release notes were not modified,
so the changes are still documented, just not in the main docs.

Allow ALTER TABLE ... ALTER CONSTRAINT ... RENAME

Joachim Wieland

Joachim Wieland

... in fact, it will be applied now in any query whatsoever.  I'm still
a bit concerned about the cycles that might be expended in failed proof
attempts, but given that CE is turned off by default, it's the user's
choice whether to expend those cycles or not.  (Possibly we should
change the simple bool constraint_exclusion parameter to something
more fine-grained?)

SET.

necessary, and be careful to refer to the right version where it is
useful to do so.  This partially reverts an ill-considered search and
replace from a few months ago.

elsewhere.

From Simon Riggs; cleanup and editorialization by Neil Conway.

>>>I think a more accurate description would be "permissions not
>>>inherited by children," and that isn't necessarily a bug.
>>
>>I agree it may not be a bug - but it's more than the permissions not
>>being inherited: the parent is affected.
>
>
> Not really, once you understand what's happening.  Unless you use
> FROM ONLY, selecting from the parent selects from the parent *and*
> its children.  The parent itself isn't affected, as queries with
> FROM ONLY should demonstrate.  I understand what you're saying --
> that there's an apparent effect on the parent -- but there really
> isn't.

Sean Burlington

whenever we generate a new OID.  This prevents occasional duplicate-OID
errors that can otherwise occur once the OID counter has wrapped around.
Duplicate relfilenode values are also checked for when creating new
physical files.  Per my recent proposal.

is used as if it were the latest (and/or still valid) SQL standard.
SQL:2003 is used in its place. Patch from Simon Riggs.

reference page for SQL commands, so that the link text is italicized.

no longer include OIDs, unless WITH OIDS is specified or the
default_with_oids configuration parameter is enabled. Update the docs
accordingly.

7.4 interactive docs.

by Troels Arvin, Simon Riggs, Elein Mustain

Make spelling of SQL standard names uniform.

output.

NO ACTION check is deferrable.  This seems to be a closer approximation
to what the SQL spec says than what we were doing before, and it prevents
some anomalous behaviors that are possible now that triggers can fire
during the execution of PL functions.
Stephan Szabo.

and into ddl.sgml.  Rewrite for more completeness and (hopefully)
clarity.