- 06 3月, 2011 5 次提交
-
-
由 Andrew Dunstan 提交于
-
由 Tom Lane 提交于
It's more likely that pg_pltemplate will go away in the future than that we'll add additional specialized infrastructure for it.
-
由 Tom Lane 提交于
The original scheme for this was to symlink plpython.$DLSUFFIX to plpython2.$DLSUFFIX, but that doesn't work on Windows, and only accidentally failed to fail because of the way that CREATE LANGUAGE created or didn't create new C functions. My changes of yesterday exposed the weakness of that approach. To fix, get rid of the symlink and make pg_pltemplate show what's really going on.
-
由 Tom Lane 提交于
In createlang this is a one-line change. In droplang there's a whole lot of cruft that can be discarded since the extension mechanism now manages removal of the language's support functions. Also, add deprecation notices to these two programs' reference pages, since per discussion we may toss them overboard altogether in a release or two.
-
由 Robert Haas 提交于
Noted by Andy Colson
-
- 05 3月, 2011 11 次提交
-
-
由 Peter Eisentraut 提交于
-
由 Robert Haas 提交于
-
由 Robert Haas 提交于
-
由 Robert Haas 提交于
In preparation for 9.1alpha4 release notes, where only the 9.1alpha4 features will be emphasized.
-
由 Tom Lane 提交于
Recommend use of CREATE EXTENSION rather than plain CREATE LANGUAGE where relevant. Encourage PL authors to provide extension wrappers for their PLs.
-
由 Tom Lane 提交于
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).
-
由 Robert Haas 提交于
This avoids duplicate (and not-quite-matching) code, and makes the logic for SECURITY LABEL match COMMENT and ALTER EXTENSION ADD/DROP.
-
由 Peter Eisentraut 提交于
It is possible that an expression ends up with a collatable type but without a collation. CREATE TABLE AS could then create a table based on that. But such a column cannot be dumped with valid SQL syntax, so we disallow creating such a column. per test report from Noah Misch
-
由 Tom Lane 提交于
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.
-
由 Peter Eisentraut 提交于
This is the same check that would happen later when the collation is used, but it's friendlier to check the collation already when it is created.
-
由 Tom Lane 提交于
Instead, just act as though the certificate file(s) are not present. There is only one case where this need be a hard failure condition: when sslmode is verify-ca or verify-full, not having a root cert file is an error. Change the logic so that we complain only in that case, and otherwise fall through cleanly. This is how it used to behave pre-9.0, but my patch 4ed4b6c5 of 2010-05-26 broke the case. Per report from Christian Kastner.
-
- 04 3月, 2011 5 次提交
-
-
由 Heikki Linnakangas 提交于
CheckForSerializableConflictOut(), because it can set hint bits. YAMAMOTO Takashi
-
由 Andrew Dunstan 提交于
Mostly text supplied by Jan Urbański.
-
由 Tom Lane 提交于
Instead of manually maintaining the "implementation of XXX operator" comments in pg_proc.h, delete all those entries and let initdb create them via a join. To let initdb figure out which name to use when there is a conflict, change the comments for deprecated operators to say they are deprecated --- which seems like a good thing to do anyway.
-
由 Tom Lane 提交于
Although there remains some debate about how CREATE TYPE should represent the collation property, this doesn't really affect what we need to do in citext's script, so go ahead and fix that.
-
由 Tom Lane 提交于
This works around the problem noted by Yamamoto Takashi in bug #5906, that there were code paths whereby we could reach AtCleanup_Portals with a portal's cleanup hook still unexecuted. The changes I made a few days ago were intended to prevent that from happening, and I think that on balance it's still a good thing to avoid, so I don't want to remove the Assert in AtCleanup_Portals. Hence do this instead.
-
- 03 3月, 2011 10 次提交
-
-
由 Michael Meskes 提交于
Andy Colson <andy@squeakycode.net>.
-
由 Heikki Linnakangas 提交于
Andrey Popp
-
由 Tom Lane 提交于
Now that btree_gist contains a reference to isinf(), this is necessary at least on some platforms. Per buildfarm.
-
由 Tom Lane 提交于
Historically, we've not had separate comments for built-in pg_operator entries, but relied on the comments for the underlying functions. The trouble with this approach is that there isn't much of anything to suggest to users that they'd be better off using the operators instead. So, move all the relevant comments into pg_operator, and give each underlying function a comment that just says "implementation of XXX operator". There are only about half a dozen cases where it seems reasonable to use the underlying function interchangeably with the operator; in these cases I left the same comment in place on the function as on the operator. While at it, establish a policy that every built-in function and operator entry should have a comment: there are now queries in the opr_sanity regression test that will complain if one doesn't. This only required adding a dozen or two more entries than would have been there anyway. I also spent some time trying to eliminate gratuitous inconsistencies in the style of the comments, though it's hopeless to suppose that more won't creep in soon enough. Per my proposal of 2010-10-15.
-
由 Peter Eisentraut 提交于
This is faked information like for domains.
-
由 Tom Lane 提交于
-
由 Tom Lane 提交于
This extends GiST's support for nearest-neighbor searches to many of the standard data types. Teodor Sigaev
-
由 Peter Eisentraut 提交于
Mapped to NetBSD, the closest existing match. (Even though DragonFly BSD is derived from FreeBSD, the shared library version numbering matches NetBSD, and the rest is mostly the same among all BSD variants.) per "Rumko"
-
由 Tom Lane 提交于
Time spent executing AFTER triggers is not included in the runtime of the associated ModifyTable node; in my patch of yesterday I confused queuing of these triggers with their actual execution. Spotted by Marko Tiikkaja.
-
- 02 3月, 2011 8 次提交
-
-
由 Andrew Dunstan 提交于
Patch from Jan Urbański.
-
由 Peter Eisentraut 提交于
plpython_subtransaction test needs a separate expected file specifically for Python 2.5.
-
由 Heikki Linnakangas 提交于
it a lot more useful for determining which standby is most up-to-date, for example. There was long discussions on whether overwriting existing existing WAL makes sense to begin with, and whether we should do some more extensive variable renaming, but this change nevertheless seems quite uncontroversial. Fujii Masao, reviewed by Jeff Janes, Robert Haas, Stephen Frost.
-
由 Heikki Linnakangas 提交于
Change the way UPDATEs are handled. Instead of maintaining a chain of tuple-level locks in shared memory, copy any existing locks on the old tuple to the new tuple at UPDATE. Any existing page-level lock needs to be duplicated too, as a lock on the new tuple. That was neglected previously. Store xmin on tuple-level predicate locks, to distinguish a lock on an old already-recycled tuple from a new tuple at the same physical location. Failure to distinguish them caused loops in the tuple-lock chains, as reported by YAMAMOTO Takashi. Although we don't use the chain representation of UPDATEs anymore, it seems like a good idea to store the xmin to avoid some false positives if no other reason. CheckSingleTargetForConflictsIn now correctly handles the case where a lock that's being held is not reflected in the local lock table. That happens if another backend acquires a lock on our behalf due to an UPDATE or a page split. PredicateLockPageCombine now retains locks for the page that is being removed, rather than removing them. This prevents a potentially dangerous false-positive inconsistency where the local lock table believes that a lock is held, but it is actually not. Dan Ports and Kevin Grittner
-
由 Peter Eisentraut 提交于
This was previously omitted by accident.
-
由 Tom Lane 提交于
Back-patch to 9.0, since this was changed then.
-
由 Tom Lane 提交于
Per discussion, this seems important for plans involving writable CTEs, since there can now be more than one ModifyTable node in the plan. To retain the same formatting as for target tables of scan nodes, we show only one target table, which will be the parent table in case of an UPDATE or DELETE on an inheritance tree. Individual child tables can be determined by inspecting the child plan trees if needed.
-
由 Robert Haas 提交于
Without this patch, when wal_receiver_status_interval=0, indicating that no status messages should be sent, Hot Standby feedback messages are instead sent extremely frequently. Fujii Masao, with documentation changes by me.
-
- 01 3月, 2011 1 次提交
-
-
由 Tom Lane 提交于
With this patch, portals, SQL functions, and SPI all agree that there should be only a CommandCounterIncrement between the queries that are generated from a single SQL command by rule expansion. Fetching a whole new snapshot now happens only between original queries. This is equivalent to the existing behavior of EXPLAIN ANALYZE, and it was judged to be the best choice since it eliminates one source of concurrency hazards for rules. The patch should also make things marginally faster by reducing the number of snapshot push/pop operations. The patch removes pg_parse_and_rewrite(), which is no longer used anywhere. There was considerable discussion about more aggressive refactoring of the query-processing functions exported by postgres.c, but for the moment nothing more has been done there. I also took the opportunity to refactor snapmgr.c's API slightly: the former PushUpdatedSnapshot() has been split into two functions. Marko Tiikkaja, reviewed by Steve Singer and Tom Lane
-