24 Commits (04e96bc69d541dd7b5f4d3b3daf49d291c7fcbb4)

Author	SHA1	Message	Date
Alvaro Herrera	ac50404224	Have REASSIGN OWNED work on extensions, too ... Per bug #6593, REASSIGN OWNED fails when the affected role has created an extension. Even though the user related to the extension is not nominally the owner, its OID appears on pg_shdepend and thus causes problems when the user is to be dropped. This commit adds code to change the "ownership" of the extension itself, not of the contained objects. This is fine because it's currently only called from REASSIGN OWNED, which would also modify the ownership of the contained objects. However, this is not sufficient for a working ALTER OWNER implementation extension. Back-patch to 9.1, where extensions were introduced. Bug #6593 reported by Emiliano Leporati.	14 years ago
Tom Lane	ec3e183ec5	Disallow deletion of CurrentExtensionObject while running extension script. ... While the deletion in itself wouldn't break things, any further creation of objects in the script would result in dangling pg_depend entries being added by recordDependencyOnCurrentExtension(). An example from Phil Sorber convinced me that this is just barely likely enough to be worth expending a couple lines of code to defend against. The resulting error message might be confusing, but it's better than leaving corrupted catalog contents for the user to deal with.	14 years ago
Tom Lane	dbd35a972f	Throw a useful error message if an extension script file is fed to psql. ... We have seen one too many reports of people trying to use 9.1 extension files in the old-fashioned way of sourcing them in psql. Not only does that usually not work (due to failure to substitute for MODULE_PATHNAME and/or @extschema@), but if it did work they'd get a collection of loose objects not an extension. To prevent this, insert an \echo ... \quit line that prints a suitable error message into each extension script file, and teach commands/extension.c to ignore lines starting with \echo. That should not only prevent any adverse consequences of loading a script file the wrong way, but make it crystal clear to users that they need to do it differently now. Tom Lane, following an idea of Andrew Dunstan's. Back-patch into 9.1 ... there is not going to be much value in this if we wait till 9.2.	14 years ago
Tom Lane	3d332c8f38	Improve and simplify CREATE EXTENSION's management of GUC variables. ... CREATE EXTENSION needs to transiently set search_path, as well as client_min_messages and log_min_messages. We were doing this by the expedient of saving the current string value of each variable, doing a SET LOCAL, and then doing another SET LOCAL with the previous value at the end of the command. This is a bit expensive though, and it also fails badly if there is anything funny about the existing search_path value, as seen in a recent report from Roger Niederland. Fortunately, there's a much better way, which is to piggyback on the GUC infrastructure previously developed for functions with SET options. We just open a new GUC nesting level, do our assignments with GUC_ACTION_SAVE, and then close the nesting level when done. This automatically restores the prior settings without a re-parsing pass, so (in principle anyway) there can't be an error. And guc.c still takes care of cleanup in event of an error abort. The CREATE EXTENSION code for this was modeled on some much older code in ri_triggers.c, which I also changed to use the better method, even though there wasn't really much risk of failure there. Also improve the comments in guc.c to reflect this additional usage.	14 years ago
Tom Lane	7f7fdd2a17	Make CREATE EXTENSION check schema creation permissions. ... When creating a new schema for a non-relocatable extension, we neglected to check whether the calling user has permission to create schemas. That didn't matter in the original coding, since we had already checked superuserness, but in the new dispensation where users need not be superusers, we should check it. Use CreateSchemaCommand() rather than calling NamespaceCreate() directly, so that we also enforce the rules about reserved schema names. Per complaint from KaiGai Kohei, though this isn't the same as his patch.	15 years ago
Tom Lane	7c88443399	Fix another oversight in logging of changes in postgresql.conf settings. ... We were using GetConfigOption to collect the old value of each setting, overlooking the possibility that it didn't exist yet. This does happen in the case of adding a new entry within a custom variable class, as exhibited in bug #6097 from Maxim Boguk. To fix, add a missing_ok parameter to GetConfigOption, but only in 9.1 and HEAD --- it seems possible that some third-party code is using that function, so changing its API in a minor release would cause problems. In 9.0, create a near-duplicate function instead.	15 years ago
Peter Eisentraut	a0b5146b25	Message style and spelling improvements	15 years ago
Bruce Momjian	bf50caf105	pgindent run before PG 9.1 beta 1.	15 years ago
Robert Haas	a432e2783b	Add post-creation hook for extensions, consistent with other object types. ... KaiGai Kohei	15 years ago
Tom Lane	63b656b7bf	Create extension infrastructure for the core procedural languages. ... This mostly just involves creating control, install, and update-from-unpackaged scripts for them. However, I had to adjust plperl and plpython to not share the same support functions between variants, because we can't put the same function into multiple extensions. catversion bump forced due to new contents of pg_pltemplate, and because initdb now installs plpgsql as an extension not a bare language. Add support for regression testing these as extensions not bare languages. Fix a couple of other issues that popped up while testing this: my initial hack at pg_dump binary-upgrade support didn't work right, and we don't want an extra schema permissions test after all. Documentation changes still to come, but I'm committing now to see whether the MSVC build scripts need work (likely they do).	15 years ago
Tom Lane	8d3b421f5f	Allow non-superusers to create (some) extensions. ... Remove the unconditional superuser permissions check in CREATE EXTENSION, and instead define a "superuser" extension property, which when false (not the default) skips the superuser permissions check. In this case the calling user only needs enough permissions to execute the commands in the extension's installation script. The superuser property is also enforced in the same way for ALTER EXTENSION UPDATE cases. In other ALTER EXTENSION cases and DROP EXTENSION, test ownership of the extension rather than superuserness. ALTER EXTENSION ADD/DROP needs to insist on ownership of the target object as well; to do that without duplicating code, refactor comment.c's big switch for permissions checks into a separate function in objectaddress.c. I also removed the superuserness checks in pg_available_extensions and related functions; there's no strong reason why everybody shouldn't be able to see that info. Also invent an IF NOT EXISTS variant of CREATE EXTENSION, and use that in pg_dump, so that dumps won't fail for installed-by-default extensions. We don't have any of those yet, but we will soon. This is all per discussion of wrapping the standard procedural languages into extensions. I'll make those changes in a separate commit; this is just putting the core infrastructure in place.	15 years ago
Tom Lane	a874fe7b4c	Refactor the executor's API to support data-modifying CTEs better. ... The originally committed patch for modifying CTEs didn't interact well with EXPLAIN, as noted by myself, and also had corner-case problems with triggers, as noted by Dean Rasheed. Those problems show it is really not practical for ExecutorEnd to call any user-defined code; so split the cleanup duties out into a new function ExecutorFinish, which must be called between the last ExecutorRun call and ExecutorEnd. Some Asserts have been added to these functions to help verify correct usage. It is no longer necessary for callers of the executor to call AfterTriggerBeginQuery/AfterTriggerEndQuery for themselves, as this is now done by ExecutorStart/ExecutorFinish respectively. If you really need to suppress that and do it for yourself, pass EXEC_FLAG_SKIP_TRIGGERS to ExecutorStart. Also, refactor portal commit processing to allow for the possibility that PortalDrop will invoke user-defined code. I think this is not actually necessary just yet, since the portal-execution-strategy logic forces any non-pure-SELECT query to be run to completion before we will consider committing. But it seems like good future-proofing.	15 years ago
Tom Lane	65076269ea	Make a no-op ALTER EXTENSION UPDATE give just a NOTICE, not ERROR. ... This seems a bit more user-friendly.	15 years ago
Tom Lane	555353c0c5	Rearrange extension-related views as per recent discussion. ... The original design of pg_available_extensions did not consider the possibility of version-specific control files. Split it into two views: pg_available_extensions shows information that is generic about an extension, while pg_available_extension_versions shows all available versions together with information that could be version-dependent. Also, add an SRF pg_extension_update_paths() to assist in checking that a collection of update scripts provide sane update path sequences.	15 years ago
Tom Lane	e693e97d75	Support replacing MODULE_PATHNAME during extension script file execution. ... This avoids the need to find a way to make PGXS' .sql.in-to-.sql rule insert the right thing. We'll just deprecate use of that hack for extensions.	15 years ago
Tom Lane	27d5d7ab10	Change the naming convention for extension files to use double dashes. ... This allows us to have an unambiguous rule for deconstructing the names of script files and secondary control files, without having to forbid extension and version names from containing any dashes. We do have to forbid them from containing double dashes or leading/trailing dashes, but neither restriction is likely to bother anyone in practice. Per discussion, this seems like a better solution overall than the original design.	15 years ago
Tom Lane	6c2e734f0a	Refactor ALTER EXTENSION UPDATE to have cleaner multi-step semantics. ... This change causes a multi-step update sequence to behave exactly as if the updates had been commanded one at a time, including updating the "requires" dependencies afresh at each step. The initial implementation took the shortcut of examining only the final target version's "requires" and changing the catalog entry but once. But on reflection that's a bad idea, since it could lead to executing old update scripts under conditions different than they were designed/tested for. Better to expend a few extra cycles and avoid any surprises. In the same spirit, if a CREATE EXTENSION FROM operation involves applying a series of update files, it will act as though the CREATE had first been done using the initial script's target version and then the additional scripts were invoked with ALTER EXTENSION UPDATE. I also removed the restriction about not changing encoding in secondary control files. The new rule is that a script is assumed to be in whatever encoding the control file(s) specify for its target version. Since this reimplementation causes us to read each intermediate version's control file, there's no longer any uncertainty about which encoding setting would get applied.	15 years ago
Tom Lane	24d1280c4d	Clean up installation directory choices for extensions. ... Arrange for the control files to be in $SHAREDIR/extension not $SHAREDIR/contrib, since we're generally trying to deprecate the term "contrib" and this is a once-in-many-moons opportunity to get rid of it in install paths. Fix PGXS to install the $EXTENSION file into that directory no matter what MODULEDIR is set to; a nondefault MODULEDIR should only affect the script and secondary extension files. Fix the control file directory parameter to be interpreted relative to $SHAREDIR, to avoid a surprising disconnect between how you specify that and what you set MODULEDIR to. Per discussion with David Wheeler.	15 years ago
Tom Lane	1214749901	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	15 years ago
Tom Lane	01467d3e4f	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.	15 years ago
Tom Lane	caddcb8f4b	Fix pg_upgrade to handle extensions. ... This follows my proposal of yesterday, namely that we try to recreate the previous state of the extension exactly, instead of allowing CREATE EXTENSION to run a SQL script that might create some entirely-incompatible on-disk state. In --binary-upgrade mode, pg_dump won't issue CREATE EXTENSION at all, but instead uses a kluge function provided by pg_upgrade_support to recreate the pg_extension row (and extension-level pg_depend entries) without creating any member objects. The member objects are then restored in the same way as if they weren't members, in particular using pg_upgrade's normal hacks to preserve OIDs that need to be preserved. Then, for each member object, ALTER EXTENSION ADD is issued to recreate the pg_depend entry that marks it as an extension member. In passing, fix breakage in pg_upgrade's enum-type support: somebody didn't fix it when the noise word VALUE got added to ALTER TYPE ADD. Also, rationalize parsetree representation of COMMENT ON DOMAIN and fix get_object_address() to allow OBJECT_DOMAIN.	15 years ago
Tom Lane	5bc178b89f	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.	15 years ago
Tom Lane	375e5b0a68	Suppress some compiler warnings in recent commits. ... Older versions of gcc tend to throw "variable might be clobbered by `longjmp' or `vfork'" warnings whenever a variable is assigned in more than one place and then used after the end of a PG_TRY block. That's reasonably easy to work around in execute_extension_script, and the overhead of unconditionally saving/restoring the GUC variables seems unlikely to be a serious concern. Also clean up logic in ATExecValidateConstraint to make it easier to read and less likely to provoke "variable might be used uninitialized in this function" warnings.	15 years ago
Tom Lane	d9572c4e3b	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	15 years ago