- 07 2月, 2017 2 次提交
-
-
由 Daniel Gustafsson 提交于
-
由 Daniel Gustafsson 提交于
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
-
- 14 11月, 2016 1 次提交
-
-
由 Yandong Yao 提交于
- 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
-
- 10 3月, 2016 1 次提交
-
-
由 Kuien Liu 提交于
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
-
- 18 11月, 2015 1 次提交
-
-
由 Heikki Linnakangas 提交于
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.
-
- 28 10月, 2015 1 次提交
-
-