The SAN FTS failover strategy is deprecated and no longer maintained,
as it's no longer needed. Retire the dead code to clean up. Since we
currently are in catalog freeze, the gp_san_configuration catalog is
left in place but will be removed once we open up for the next major
version cycle. Since the gp_san_config header file contains catalogs
for general FTS fault strategies, rename the file for clarity.

Rather than relying on always having a full cloned repository when
building, add fallbacks which work for trees with constrained (such
as shallow-cloned trees), or no, history. When the tagged commit is
reachable, use git describe, else rely on the version string in
configure since that's required to always be there regardless of
distribution mode. If we have git tree then include the HEAD sha1
as well.

While there, clean up versioning to more clearly separate us from
upstream.

  - Add 2 catalog tables for resource group
  - add one column in pg_authid to record the resource group of a role
  - bump catalog version
  - hard code default resource group of roles temporarily
Signed-off-by: NKenan Yao <kyao@pivotal.io>

* Update foreign key json file name to 5.0

* This was breaking gpcheckcat which assumes the json file corresponds
* to the current greenplum version.
* Update docs for generating json file.

Authors: Chris Hajas and Jamie McAtamney

- continue to merge the remaining part of extension framework,
include alter extension, extension view, extension upgrade,
psql support.
- Make plpgsql available as an extension.
- Support dump for extension.
- Use new oid dispatch method to for extension oid

commit d9572c4e
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Tue Feb 8 16:08:41 2011 -0500

    Core support for "extensions", which are packages of SQL objects.

    This patch adds the server infrastructure to support extensions.
    There is still one significant loose end, namely how to make it play nice
    with pg_upgrade, so I am not yet committing the changes that would make
    all the contrib modules depend on this feature.

    In passing, fix a disturbingly large amount of breakage in
    AlterObjectNamespace() and callers.

    Dimitri Fontaine, reviewed by Anssi Kääriäinen,
    Itagaki Takahiro, Tom Lane, and numerous others

commit 5bc178b8
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Wed Feb 9 11:55:32 2011 -0500

    Implement "ALTER EXTENSION ADD object".

    This is an essential component of making the extension feature usable;
    first because it's needed in the process of converting an existing
    installation containing "loose" objects of an old contrib module into
    the extension-based world, and second because we'll have to use it
    in pg_dump --binary-upgrade, as per recent discussion.

    Loosely based on part of Dimitri Fontaine's ALTER EXTENSION UPGRADE
    patch.

commit 01467d3e
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Thu Feb 10 17:36:44 2011 -0500

    Extend "ALTER EXTENSION ADD object" to permit "DROP object" as well.

    Per discussion, this is something we should have sooner rather than later,
    and it doesn't take much additional code to support it.

commit 12147499
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Fri Feb 11 21:25:20 2011 -0500

    Add support for multiple versions of an extension and ALTER EXTENSION UPDATE.

    This follows recent discussions, so it's quite a bit different from
    Dimitri's original.  There will probably be more changes once we get a bit
    of experience with it, but let's get it in and start playing with it.

    This is still just core code.  I'll start converting contrib modules
    shortly.

    Dimitri Fontaine and Tom Lane

Instead of carrying a "new OID" field in all the structs that represent
CREATE statements, introduce a generic mechanism for capturing the OIDs
of all created objects, dispatching them to the QEs, and using those same
OIDs when the corresponding objects are created in the QEs. This allows
removing a lot of scattered changes in DDL command handling, that was
previously needed to ensure that objects are assigned the same OIDs in
all the nodes.

This also provides the groundwork for pg_upgrade to dictate the OIDs to use
for upgraded objects. The upstream has mechanisms for pg_upgrade to dictate
the OIDs for a few objects (relations and types, at least), but in GPDB,
we need to preserve the OIDs of almost all object types.

These were only used by CaQL. I didn't realize that earlier..

The previous commits have removed all usage of CaQL. It's no longer
needed.

System catalogs are now defined like in the upstream, without any special
tidycat headers.

Note: This doesn't change the way pg_proc_gp.h is generated from
pg_proc.sql, by catullus.pl.

This comes with a replacement for generating 4.3.json:
src/backend/catalog/process_foreign_keys.pl. The foreign keys were the
only thing that the json file was used for. AFAIK gpcheckcat is the only
tool that reads that file, and it only paid attention to the foreign key
information.

While working on this, I noticed that a few tables were missing foreign
key declarations. I added FIXME comments on them. Also, a few tables used
to have "vector" references, e.g. pg_index.indclass was an oidvector, where
each element of the array points to pg_class.oid. AFAICS, those
declarations were actually not used for anything. I left those in place as
comments, in case we want to add support in gpcheckcat and the new
process_foreign_keys.pl tool for them, but for now they're just
documentation.

This also removes pablopcatso.pl. It read the json file (Ok, so there was
one more user besides gpcheckcat for it), which is now gone. We could
create a tool that reads the same information straight from the header
files, or from a live database, but it was just a developer aid, and I
don't think anyone's used it for quite a while, so I don't think we need a
replacement.

gp_read_error_log and gp_truncate_error_log were two functions which were added
in 4.3.3.0 to support the new error logging functionality for external tables.
They were added to a "hidden" catalog in order to prevent bumping up the
catalog version in a minor version release. We need to add them to the true
catalog in a major release.

Also in the process remove hiddencat mechanism since apart from the above two
functions no other functions use it.

This table is not used anywhere in the code.

gpverify functionality was planned in past to deliver online
verification of primary and mirror. It's completely dead code as never
exposed this functionality and have no plans either. It eliminates
creation of unused processes, extra directory, some shared memory and
all.

They are not generated files anymore.

Use the standard initdb mechanism for it, instead of having bespoken code
in gpinitsystem.

Also remove the unnecessarily complicated logic to generate gp_toolkit.sql
from gp_toolkit.sql.in. All the JETPACK_* variables were constants, and
there is particular need in making the gp_toolkit functions relocatable to
different schemas or prefixes, so just hardcode them and remove the sed
magic.

Rewrite the file header of gp_toolkit.sql. The legal blurp is not needed,
make the header look more like that of information_schema.sql and
system_views.sql.

Remove compaction_info.sql. It was only needed for old in-place
upgrade from 4.3.x to 4.3.4.2, which is not relevant for master branch.

Fix the "jetpack" bugbuster regression test. It was originally written to
test the gp_toolkit views, but gp_toolkit was in fact not installed in
bugbuster, and the expected output just contained a bunch of "relation
does not exist" errors. Now it actually tests gp_toolkit again. Some of
the test queries didn't produce repeateable results, due to differing oids,
differences in table sizes, and other tables created by previous tests, so
fixed those too.

This has a small user-visible difference: gp_toolkit schema is now also
installed in template0. That caused the difference in the expected outputs:
pg_regress creates the "regression" database using template0 as the
template, so gp_toolkit used to not be installed in it, but it is now.

It was just syntax and catalogs, you couldn't actually do anything useful
with it. Remove it, so that we have less code to maintain, until it's time
to merge this stuff from upstream again when we merge with PostgreSQL 8.4.
It's probably easier to merge this back at that point than maintain this
backported version in the meanwhile. Less effort now, until we reach that
point, and once we get to the point in 8.4 that we merge this in, we'll
have all the preceding patches applied already, so it should merge quite
smoothly.

This splits pg_proc.h into two parts: pg_proc.h and pg_proc_gp.h. After the
split, pg_proc.h contains functions we've inherited from upstream, and is
mostly identical to the upstream version. This makes diffing and merging
with upstream easier. All the upstream functions have been removed from
pg_proc.sql, as they are no longer auto-generated. Instead of modifying
pg_proc.h, catullus.pl is now used to create pg_proc_gp.h, which contains
all the auto-generated DATA entries for the functions in pg_proc.sql.

For the upstream-inherited DATA entries in pg_proc.h, remove the columns
that are not present in upstream. This was needed again to make pg_proc.h
closer to the upstream version. Also, remove auto-generated comments and
revert whitespace changes compared to upstream.

To compensate for the missing columns, introduce a new perl script,
processs_col_defaults.pl that is run at build time, which adds the missing
columns back to any DATA rows that miss them, before they are fed to
genbki.sh. All the GPDB-added columns are annotated with a magic
GPDB_COLUMN_DEFAULT() macro, similar to the CATALOG() and DATA() macros
which tells process_col_defaults.pl what values to insert into the missing
columns.

Remove tidycat2 regression test. It tested that all the functions in
pg_catalog came from pg_proc.sql, but that is no longer true. Only the
GPDB-added ones are now in pg_proc.sql.

Oleg Bartunov and Teodor Sigaev, but I did a lot of editorializing,
so anything that's broken is probably my fault.

Documentation is nonexistent as yet, but let's land the patch so we can
get some portability testing done.

pg_type.typtype whereever practical.  Tom Dunstan, with some kibitzing
from Tom Lane.

used to be part of libpq's exported interface many releases ago, but now
it's no longer necessary to make it accessible to clients.

cases.  Operator classes now exist within "operator families".  While most
families are equivalent to a single class, related classes can be grouped
into one family to represent the fact that they are semantically compatible.
Cross-type operators are now naturally adjunct parts of a family, without
having to wedge them into a particular opclass as we had done originally.

This commit restructures the catalogs and cleans up enough of the fallout so
that everything still works at least as well as before, but most of the work
needed to actually improve the planner's behavior will come later.  Also,
there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way
to create a new family right now is to allow CREATE OPERATOR CLASS to make
one by default.  I owe some more documentation work, too.  But that can all
be done in smaller pieces once this infrastructure is in place.

created in the bootstrap phase proper, rather than added after-the-fact
by initdb.  This is cleaner than before because it allows us to retire the
undocumented ALTER TABLE ... CREATE TOAST TABLE command, but the real reason
I'm doing it is so that toast tables of shared catalogs will now have
predetermined OIDs.  This will allow a reasonably clean solution to the
problem of locking tables before we load their relcache entries, to appear
in a forthcoming patch.

comments on cluster global objects like databases, tablespaces, and
roles.

It touches a lot of places, but not much in the way of big changes.  The
only design decision I made was to duplicate the query and manipulation
functions rather than to try and have them handle both shared and local
comments.  I believe this is simpler for the code and not an issue for
callers because they know what type of object they are dealing with.
This has resulted in a shobj_description function analagous to
obj_description and backend functions [Create/Delete]SharedComments
mirroring the existing [Create/Delete]Comments functions.

pg_shdescription.h goes into src/include/catalog/

Kris Jurka

for procedural languages.  This replaces the hard-wired table I had
originally proposed as a stopgap solution.  For the moment, the initial
contents only include languages shipped with the core distribution.

few loose ends to be dealt with, but it seems to work.  Alvaro Herrera,
based on the contrib code by Matthew O'Connor.

have adequate mechanisms for tracking the contents of databases and
tablespaces).  This solves the longstanding problem that you can drop a
user who still owns objects and/or has access permissions.
Alvaro Herrera, with some kibitzing from Tom Lane.

and pg_auth_members.  There are still many loose ends to finish in this
patch (no documentation, no regression tests, no pg_dump support for
instance).  But I'm going to commit it now anyway so that Alvaro can
make some progress on shared dependencies.  The catalog changes should
be pretty much done.

(fairly closely, I hope) to the current PL/Perl implementation.

David Fetter

There are various things left to do: contrib dbsize and oid2name modules
need work, and so does the documentation.  Also someone should think about
COMMENT ON TABLESPACE and maybe RENAME TABLESPACE.  Also initlocation is
dead, it just doesn't know it yet.

Gavin Sherry and Tom Lane.

run the data through cpp, and we know of at least one platform where
unusual cpp behavior breaks the process.  So remove the cpp step,
and make consequent simplifications.

$Header: -> $PostgreSQL Changes ...

uselessly invoke it in parallel in the first place.

parts.  Standardize spelling of comments in pg_config.h.

in the documentation from that same data.

source tree.