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.

Just some random things I happened to spot while reading code.

User could use VARIADIC to specify parameter list when defining UDF
if they want to use variadic parameters. It is easier for user to write
only one variadic function instead of same name function with different
parameters. An example for using variadic:
create function concat(text, variadic anyarray) returns text as $$
select array_to_string($2, $1);
$$ language sql immutable strict;

select concat('%', 1, 2, 3, 4, 5);

NOTE: The variadic change set is ported from upstream of PostgreSQL:
commit 517ae403
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Thu Dec 18 18:20:35 2008 +0000

Code review for function default parameters patch.  Fix numerous problems as
per recent discussions.  In passing this also fixes a couple of bugs in
the previous variadic-parameters patch.

commit 6563e9e2
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Wed Jul 16 16:55:24 2008 +0000

Add a "provariadic" column to pg_proc to eliminate the remarkably expensive
need to deconstruct proargmodes for each pg_proc entry inspected by
FuncnameGetCandidates().  Fixes function lookup performance regression
caused by yesterday's variadic-functions patch.

In passing, make pg_proc.probin be NULL, rather than a dummy value '-',
in cases where it is not actually used for the particular type of function.
This should buy back some of the space cost of the extra column.

commit d89737d3
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Wed Jul 16 01:30:23 2008 +0000

Support "variadic" functions, which can accept a variable number of arguments
so long as all the trailing arguments are of the same (non-array) type.
The function receives them as a single array argument (which is why they
have to all be the same type).

It might be useful to extend this facility to aggregates, but this patch
doesn't do that.

This patch imposes a noticeable slowdown on function lookup --- a follow-on
patch will fix that by adding a redundant column to pg_proc.

Conflicts:
	src/backend/gpopt/gpdbwrappers.cpp

This patch replaces all occurrences of pgsql-bugs@postgresql.org with
bugs@greenplum.org. Pointers to the pgsql-bugs mailinglist in the code
remain as they re. Regression and BugBuster tests are also patched.

Instead of creating a mock version of every backend object file, only
create mock files as needed by individual tests. Speeds up the build, and
is nicer anyway.

This inverts the logic of the <testname>_REAL_OBJS mechanism. We now link
with the real version of each object file, *except* those listed in
<testname>_MOCK_OBJS variable.

Some tests were already doing this, but it seems nicer to default to using
the real memory manager for all tests. An individual test can still opt-out
by listing the relevant files in <testname>_MOCK_OBJS. Some tests had had
to jump through hoops to mock the memory manager, which is no longer
necessary.

There are a bunch of backend files that are never mocked, but always linked
into test program as is. List those in Makefile.mock, so that every Makefile
doesn't need to list them. Makes the makefiles simpler, and you need less
boilerplate code when adding a new test program.

Not all of these backend files were listed in the _REAL_OBJS variable of
every test, but in those tests that they were not, they were also not used,
so it doesn't matter if we use the real or mock version.

This way we don't need to link the whole backend into client mock programs.
We've gotten away with it so far, but it would cause clashes if one of the
client programs contained a function or global variable with same name as
in the backend. And of course it's completely unnecessary anyway.

The only reason we did that was to keep the OIDs the same across major
version upgrades, because the old catalog upgrade mechanism relied on
being able to read old catalog version with new binaries. We no longer try
to maintain that property - future upgrades will use pg_upgrade or
something similar that can deal with more drastic catalog changes.

This allows removing the hacks in bootparse.y, toasting.c, and elsewhere,
reducing the chance of merge conflicts in the future.

The current plan is to use something like pg_upgrade for future in-place
upgrades. The gpupgrade mechanism will not scale to the kind of drastic
catalog and other data directory layout changes that are coming as we
merge with later PostgreSQL releases.

Kept gpupgrademirror for now. Need to check if there's some logic that's
worth saving, for a possible pg_upgrade based solution later.

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 makes merging and diffing with upstream easier. There were so many
GPDB-added GUCs in guc.c that "git merge" didn't handle it very well, and
you easily got merge conflicts that were error-prone to fix manually.

I kept a few GUCs in guc.c that are not present in REL8_2_0, because they
were backported from later PostgreSQL versions, rather than being
completely GPDB-specific.

Clean up the diff between guc.c and upstream, by removing unnecessary
includes, reordering a few GUCs to match upstream better, and similar
cosmetic changes.

I had to move MAX_KILOBYTES from guc.c to guc_tables.h, because guc_gp.c
needs it too. I also had to export assign_msglvl() function from guc.c, so
that it can be called from other assign_* functions from guc_gp.c. And I
had to add the code to process the ConfigureNames*_gp arrays in addition
to the upstream ones. These things increase the diff against upstream, but
not by too much, IMHO. I also copy-pasted constants like MS_PER_S and
KB_PER_MB, which seems safe as those are natural constants, and should
never change.

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.

Now that we no longer forcibly compile strlcpy.c, and only compile and link
it into strlcpy.o into libpgport when needed, this is no longer needed.
Furthermore, it caused the linking to fail on platforms that don't need
strlcpy.o, like OS X.

If DROP has to wait for a lock on the relation after its OID was looked up, it
may happen that the name is no longer valid by the time DROP acquires the lock.

This case is handled by pulling a function from upstream commit
	commit 4240e429
	Author: Robert Haas <rhaas@postgresql.org>
	Date:   Fri Jul 8 22:19:30 2011 -0400
	Try to acquire relation locks in RangeVarGetRelid.

it was checking a pg_constraint OID instead of pg_class OID, resulting in
"relation with OID nnnnn does not exist" failures for anyone who wasn't
owner of the table being examined.  Per bug #2848 from Laurence Rowe.

Note: for existing 8.2 installations a simple version update won't fix this;
the easiest fix is to CREATE OR REPLACE this view with the corrected
definition.

per-column options for btree indexes.  The planner's support for this is still
pretty rudimentary; it does not yet know how to plan mergejoins with
nondefault ordering options.  The documentation is pretty rudimentary, too.
I'll work on improving that stuff later.

Note incompatible change from prior behavior: ORDER BY ... USING will now be
rejected if the operator is not a less-than or greater-than member of some
btree opclass.  This prevents less-than-sane behavior if an operator that
doesn't actually define a proper sort ordering is selected.

back-stamped for this.

The purpose is to allow autovacuum-esq conditional vacuuming and
clustering using SQL to discover the required stats.

No documentation updates required.  Catalog version updated.

Glen Parker

about typmod representation for standard types out into type-specific
typmod I/O functions.  Teodor Sigaev, with some editorialization by
Tom Lane.

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.

identify long-running transactions. Since we already need to record
the transaction-start time (e.g. for now()), we don't need any
additional system calls to report this information.

Catversion bumped, initdb required.

vacuum/analyze timestamp columns at the end, rather than at a random
spot in the middle as in the original patch.  This was deemed more usable
as well as less likely to break existing application code.  initdb forced
accordingly.  In passing, remove former kluge for initializing
pg_stat_file()'s pg_proc entry --- bootstrap mode was fixed recently
so that this can be done without any hacks, but I overlooked this usage.

added to information_schema (per a SQL2003 addition).  The original coding
failed if a referenced column participated in more than one pg_constraint
entry.  Also, it did not work if an FK relied directly on a unique index
without any constraint syntactic sugar --- this case is outside the SQL spec,
but PG has always supported it, so it's reasonable for our information_schema
to handle it too.  Per bug#2750 from Stephen Haberman.

Although this patch changes the initial catalog contents, I didn't force
initdb.  Any beta3 testers who need the fix can install it via CREATE OR
REPLACE VIEW, so forcing them to initdb seems an unnecessary imposition.

in PITR scenarios.  We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases.  Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId.  Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done.  Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database.  initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs.  Heikki Linnakangas, Simon Riggs, and Tom Lane.

from Magnus that MSVC complains about this.

and create a new view pg_timezone_names that provides information about
the zones known in the 'zic' database.  Magnus Hagander, with some
additional work by Tom Lane.

a schema is our own temp schema or another backend's temp schema, and use
these in place of some former kluges in information_schema.  Per my
proposal of yesterday.

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

position_in_unique_constraint (column newly added per SQL2003).
Greg Mullane

of 'S', and the views were not checking for table visibility with
regards to temporary tables and sequences.

Greg Sabino Mullane

didn't create a dependency from the new conversion to its schema.  Back-patch
to all supported releases.

blocking concurrent writes to the table.  Greg Stark, with a little help
from Tom Lane.

by abandoning the idea that it should say SERIAL in the dump.  Instead,
dump serial sequences and column defaults just like regular ones.
Add a new backend command ALTER SEQUENCE OWNED BY to let pg_dump recreate
the sequence-to-column dependency that was formerly created "behind the
scenes" by SERIAL.  This restores SERIAL to being truly "just a macro"
consisting of component operations that can be stated explicitly in SQL.
Furthermore, the new command allows sequence ownership to be reassigned,
so that old mistakes can be cleaned up.

Also, downgrade the OWNED-BY dependency from INTERNAL to AUTO, since there
is no longer any very compelling argument why the sequence couldn't be
dropped while keeping the column.  (This forces initdb, to be sure the
right kinds of dependencies are in there.)

Along the way, add checks to prevent ALTER OWNER or SET SCHEMA on an
owned sequence; you can now only do this indirectly by changing the
owning table's owner or schema.  This is an oversight in previous
releases, but probably not worth back-patching.