External tables cannot inherit attributes when acting as a partition
member in a partititioned table. Attribute inheritance was cleaned up
in upstream commit 02e64181 which was
part of the 8.3 merge, and as an effect of this external tables were
dumped as inheriting the partition parent attributes. Fix by always
setting the attributes as local for external tables and make it even
more explicit by altering the attribute check in dumpExternal to only
consider dropped attributes. Apply the fix to both pg_dump and
cdb_dump_agent albeit a tad differently as pg_dump has abstracted the
logic for printing column names.

Report and debugging by Chris Hajas, Lawrence Hamel and Karen Huddleston

- 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

Commits backported from upstream are listed below.

	commit 87f2ad13
	Author: Tom Lane <tgl@sss.pgh.pa.us>
	Date:   Sun Mar 27 12:51:04 2011 -0400

	    Fix plpgsql to release SPI plans when a function or DO block is freed.

	    This fixes the gripe I made a few months ago about DO blocks getting
	    slower with repeated use.  At least, it fixes it for the case where
	    the DO block isn't aborted by an error.  We could try running
	    plpgsql_free_function_memory() even during error exit, but that seems
	    a bit scary since it makes a lot of presumptions about the data
	    structures being in good shape.  It's probably reasonable to assume
	    that repeated failures of DO blocks isn't a performance-critical case.

	commit 42b2907d
	Author: Tom Lane <tgl@sss.pgh.pa.us>
	Date:   Sun Nov 29 03:02:27 2009 +0000

	    Add support for anonymous code blocks (DO blocks) to PL/Perl.

	    Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce

	commit 9048b731
	Author: Tom Lane <tgl@sss.pgh.pa.us>
	Date:   Tue Sep 22 23:43:43 2009 +0000

	    Implement the DO statement to support execution of PL code without having
	    to create a function for it.

	    Procedural languages now have an additional entry point, namely a function
	    to execute an inline code block.  This seemed a better design than trying
	    to hide the transient-ness of the code from the PL.  As of this patch, only
	    plpgsql has an inline handler, but probably people will soon write handlers
	    for the other standard PLs.

	    In passing, remove the long-dead LANCOMPILER option of CREATE LANGUAGE.

	    Petr Jelinek

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.