aboutsummaryrefslogtreecommitdiff
path: root/src/backend/commands/tablecmds.c
Commit message (Collapse)AuthorAge
...
* Teach ANALYZE to clear pg_class.relhassubclass when appropriate.Tom Lane2011-09-02
| | | | | | | | | | | | | In the past, relhassubclass always remained true if a relation had ever had child relations, even if the last subclass was long gone. While this had only marginal performance implications in most cases, it was annoying, and I'm now considering some planner changes that would raise the cost of a false positive. It was previously impractical to fix this because of race condition concerns. However, given the recent change that made tablecmds.c take ShareExclusiveLock on relations that are gaining a child (commit fbcf4b92aa64d4577bcf25925b055316b978744a), we can now allow ANALYZE to clear the flag when it's no longer relevant. There is no additional locking cost to do so, since ANALYZE takes ShareExclusiveLock anyway.
* Allow per-column foreign data wrapper options.Robert Haas2011-08-05
| | | | Shigeru Hanada, with fairly minor editing by me.
* Avoid index rebuild for no-rewrite ALTER TABLE .. ALTER TYPE.Robert Haas2011-07-18
| | | | Noah Misch. Review and minor cosmetic changes by me.
* Try to acquire relation locks in RangeVarGetRelid.Robert Haas2011-07-08
| | | | | | | | | | | | | | | | | | | | | | | | | | In the previous coding, we would look up a relation in RangeVarGetRelid, lock the resulting OID, and then AcceptInvalidationMessages(). While this was sufficient to ensure that we noticed any changes to the relation definition before building the relcache entry, it didn't handle the possibility that the name we looked up no longer referenced the same OID. This was particularly problematic in the case where a table had been dropped and recreated: we'd latch on to the entry for the old relation and fail later on. Now, we acquire the relation lock inside RangeVarGetRelid, and retry the name lookup if we notice that invalidation messages have been processed meanwhile. Many operations that would previously have failed with an error in the presence of concurrent DDL will now succeed. There is a good deal of work remaining to be done here: many callers of RangeVarGetRelid still pass NoLock for one reason or another. In addition, nothing in this patch guards against the possibility that the meaning of an unqualified name might change due to the creation of a relation in a schema earlier in the user's search path than the one where it was previously found. Furthermore, there's nothing at all here to guard against similar race conditions for non-relations. For all that, it's a start. Noah Misch and Robert Haas
* Finish disabling reduced-lock-levels-for-DDL feature.Tom Lane2011-07-07
| | | | | Previous patch only covered the ALTER TABLE changes, not changes in other commands; and it neglected to revert the documentation changes.
* Message style tweaksPeter Eisentraut2011-07-05
|
* Reset ALTER TABLE lock levels to AccessExclusiveLock in all cases.Simon Riggs2011-07-04
| | | | | Locks on inheritance parent remain at lower level, as they were before. Remove entry from 9.1 release notes.
* Fix bugs in relpersistence handling during table creation.Robert Haas2011-07-03
| | | | | | | | | | | | | | | | | Unlike the relistemp field which it replaced, relpersistence must be set correctly quite early during the table creation process, as we rely on it quite early on for a number of purposes, including security checks. Normally, this is set based on whether the user enters CREATE TABLE, CREATE UNLOGGED TABLE, or CREATE TEMPORARY TABLE, but a relation may also be made implicitly temporary by creating it in pg_temp. This patch fixes the handling of that case, and also disables creation of unlogged tables in temporary tablespace (such table indeed skip WAL-logging, but we reject an explicit specification) and creation of relations in the temporary schemas of other sessions (which is not very sensible, and didn't work right anyway). Report by Amit Khandekar.
* Enable CHECK constraints to be declared NOT VALIDAlvaro Herrera2011-06-30
| | | | | | | | | | | | | | | | | | | | | | | This means that they can initially be added to a large existing table without checking its initial contents, but new tuples must comply to them; a separate pass invoked by ALTER TABLE / VALIDATE can verify existing data and ensure it complies with the constraint, at which point it is marked validated and becomes a normal part of the table ecosystem. An non-validated CHECK constraint is ignored in the planner for constraint_exclusion purposes; when validated, cached plans are recomputed so that partitioning starts working right away. This patch also enables domains to have unvalidated CHECK constraints attached to them as well by way of ALTER DOMAIN / ADD CONSTRAINT / NOT VALID, which can later be validated with ALTER DOMAIN / VALIDATE CONSTRAINT. Thanks to Thom Brown, Dean Rasheed and Jaime Casanova for the various reviews, and Robert Hass for documentation wording improvement suggestions. This patch was sponsored by Enova Financial.
* Add notion of a "transform function" that can simplify function calls.Robert Haas2011-06-21
| | | | | | | | | | Initially, we use this only to eliminate calls to the varchar() function in cases where the length is not being reduced and, therefore, the function call is equivalent to a RelabelType operation. The most significant effect of this is that we can avoid a table rewrite when changing a varchar(X) column to a varchar(Y) column, where Y > X. Noah Misch, reviewed by me and Alexey Klyukin
* Message style and spelling improvementsPeter Eisentraut2011-06-22
|
* Rework parsing of ConstraintAttributeSpec to improve NOT VALID handling.Tom Lane2011-06-15
| | | | | | | | | | | The initial commit of the ALTER TABLE ADD FOREIGN KEY NOT VALID feature failed to support labeling such constraints as deferrable. The best fix for this seems to be to fold NOT VALID into ConstraintAttributeSpec. That's a bit more general than the documented syntax, but it allows better-targeted syntax error messages. In addition, do some mostly-but-not-entirely-cosmetic code review for the whole NOT VALID patch.
* Pgindent run before 9.1 beta2.Bruce Momjian2011-06-09
|
* Make DDL operations play nicely with Serializable Snapshot Isolation.Heikki Linnakangas2011-06-08
| | | | | | | | | | | | | | Truncating or dropping a table is treated like deletion of all tuples, and check for conflicts accordingly. If a table is clustered or rewritten by ALTER TABLE, all predicate locks on the heap are promoted to relation-level locks, because the tuple or page ids of any existing tuples will change and won't be valid after rewriting the table. Arguably ALTER TABLE should be treated like a mass-UPDATE of every row, but if you e.g change the datatype of a column, you could also argue that it's just a change to the physical layout, not a logical change. Reindexing promotes all locks on the index to relation-level lock on the heap. Kevin Grittner, with a lot of cosmetic changes by me.
* Fix vim-induced typo.Robert Haas2011-06-02
|
* Remove unused variableAlvaro Herrera2011-05-27
| | | | Cédric Villemain
* Remove incorrect HINT for use of ALTER FOREIGN TABLE on the wrong relkind.Tom Lane2011-04-25
| | | | | | | | Per discussion, removing the hint seems better than correcting it because the adjacent analogous cases in RenameRelation don't have any hints, and nobody seems to have missed 'em. Shigeru Hanada
* Refactor broken CREATE TABLE IF NOT EXISTS support.Robert Haas2011-04-25
| | | | | | | | | | | | | | | | Per bug #5988, reported by Marko Tiikkaja, and further analyzed by Tom Lane, the previous coding was broken in several respects: even if the target table already existed, a subsequent CREATE TABLE IF NOT EXISTS might try to add additional constraints or sequences-for-serial specified in the new CREATE TABLE statement. In passing, this also fixes a minor information leak: it's no longer possible to figure out whether a schema to which you don't have CREATE access contains a sequence named like "x_y_seq" by attempting to create a table in that schema called "x" with a serial column called "y". Some more refactoring of this code in the future might be warranted, but that will need to wait for a later major release.
* Make a code-cleanup pass over the collations patch.Tom Lane2011-04-22
| | | | | | | This patch is almost entirely cosmetic --- mostly cleaning up a lot of neglected comments, and fixing code layout problems in places where the patch made lines too long and then pgindent did weird things with that. I did find a bug-of-omission in equalTupleDescs().
* Allow ALTER TYPE .. ADD ATTRIBUTE .. CASCADE to recurse to descendants.Robert Haas2011-04-20
| | | | | | | Without this, adding an attribute to a typed table with an inheritance child fails, which is surprising. Noah Misch, with minor changes by me.
* Typo fix.Robert Haas2011-04-20
|
* Allow ALTER TABLE name {OF type | NOT OF}.Robert Haas2011-04-20
| | | | | | | | | | | This syntax allows a standalone table to be made into a typed table, or a typed table to be made standalone. This is possibly a mildly useful feature in its own right, but the real motivation for this change is that we need it to make pg_upgrade work with typed tables. This doesn't actually fix that problem, but it's necessary infrastructure. Noah Misch
* Add check for matching column collations in ALTER TABLE ... INHERIT.Tom Lane2011-04-17
| | | | | | | The other DDL operations that create an inheritance relationship were checking for collation match already, but this one got missed. Also fix comments that failed to mention collation checks.
* Simplify reindex_relation's API.Tom Lane2011-04-16
| | | | | | | For what seem entirely historical reasons, a bitmask "flags" argument was recently added to reindex_relation without subsuming its existing boolean argument into that bitmask. This seems a bit bizarre, so fold them together.
* Remove obsolete comment.Robert Haas2011-04-13
| | | | | | | The lock level for adding a parent table is now ShareUpdateExclusiveLock; see commit fbcf4b92aa64d4577bcf25925b055316b978744a. This comment didn't get updated to match, but it doesn't seem important to mention this detail here, so rather than updating it now, just take it out.
* Fix toast table creation.Robert Haas2011-04-13
| | | | | | | | | | | | | | | Instead of using slightly-too-clever heuristics to decide when we must create a TOAST table, just check whether one is needed every time the table is altered. Checking whether a toast table is needed is cheap enough that we needn't worry about doing it on every ALTER TABLE command, and the previous coding is apparently prone to accidental breakage: commit 04e17bae50a73af524731fa11210d5c3f7d8e1f9 broken ALTER TABLE .. SET STORAGE, which moved some actions from AT_PASS_COL_ATTRS to AT_PASS_MISC, and commit 6c5723998594dffa5d47c3cf8c96ccf89c033aae broke ALTER TABLE .. ADD COLUMN by changing the way that adding columns recurses into child tables. Noah Misch, with one comment change by me
* Clean up most -Wunused-but-set-variable warnings from gcc 4.6Peter Eisentraut2011-04-11
| | | | | | This warning is new in gcc 4.6 and part of -Wall. This patch cleans up most of the noise, but there are some still warnings that are trickier to remove.
* pgindent run before PG 9.1 beta 1.Bruce Momjian2011-04-10
|
* Clean up overly complex code for issuing some related error messages.Tom Lane2011-04-09
| | | | | The original version was unreadable, and not mechanically checkable either.
* Fix bug in propagating ALTER TABLE actions to typed tables.Robert Haas2011-04-08
| | | | | | | We need to propagate such actions to all typed table children of a given type, not just the first one. Noah Misch
* Rearrange "add column" logic to merge columns at exec time.Robert Haas2011-04-03
| | | | | | | | | The previous coding set attinhcount too high in some cases, resulting in an undumpable, undroppable column. Per bug #5856, reported by Naoya Anzai. See also commit 31b6fc06d83c6de3644c8f2921eb7de0eb92fac3, which fixes a similar bug in ALTER TABLE .. ADD CONSTRAINT. Patch by Noah Misch.
* Prevent a rowtype from being included in itself.Tom Lane2011-03-28
| | | | | | | | | | | | | | | | Eventually we might be able to allow that, but it's not clear how many places need to be fixed to prevent infinite recursion when there's a direct or indirect inclusion of a rowtype in itself. One such place is CheckAttributeType(), which will recurse to stack overflow in cases such as those exhibited in bug #5950 from Alex Perepelica. If we were sure it was the only such place, we could easily modify the code added by this patch to stop the recursion without a complaint ... but it probably isn't the only such place. Hence, throw error until such time as someone is excited enough about this type of usage to put work into making it safe. Back-patch as far as 8.3. 8.2 doesn't have the recursive call in CheckAttributeType in the first place, so I see no need to add code there in the absence of clear evidence of a problem elsewhere.
* Pass collation to makeConst() instead of looking it up internally.Tom Lane2011-03-25
| | | | | | | | | In nearly all cases, the caller already knows the correct collation, and in a number of places, the value the caller has handy is more correct than the default for the type would be. (In particular, this patch makes it significantly less likely that eval_const_expressions will result in changing the exposed collation of an expression.) So an internal lookup is both expensive and wrong.
* Make FKs valid at creation when added as column constraints.Simon Riggs2011-03-22
| | | | Bug report from Alvaro Herrera
* Revise collation derivation method and expression-tree representation.Tom Lane2011-03-19
| | | | | | | | | | | | | | | | | | | All expression nodes now have an explicit output-collation field, unless they are known to only return a noncollatable data type (such as boolean or record). Also, nodes that can invoke collation-aware functions store a separate field that is the collation value to pass to the function. This avoids confusion that arises when a function has collatable inputs and noncollatable output type, or vice versa. Also, replace the parser's on-the-fly collation assignment method with a post-pass over the completed expression tree. This allows us to use a more complex (and hopefully more nearly spec-compliant) assignment rule without paying for it in extra storage in every expression node. Fix assorted bugs in the planner's handling of collations by making collation one of the defining properties of an EquivalenceClass and by converting CollateExprs into discardable RelabelType nodes during expression preprocessing.
* Fix possible "tuple concurrently updated" error in ALTER TABLE.Robert Haas2011-03-18
| | | | | | | | | | When adding an inheritance parent to a table, an AccessShareLock on the parent isn't strong enough to prevent trouble, so take ShareUpdateExclusiveLock instead. Since this is a behavior change, albeit a fairly unobtrusive one, and since we have only one report from the field, no back-patch. Report by Jon Nelson, analysis by Alvaro Herrera, fix by me.
* Remove collation information from TypeName, where it does not belong.Tom Lane2011-03-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The initial collations patch treated a COLLATE spec as part of a TypeName, following what can only be described as brain fade on the part of the SQL committee. It's a lot more reasonable to treat COLLATE as a syntactically separate object, so that it can be added in only the productions where it actually belongs, rather than needing to reject it in a boatload of places where it doesn't belong (something the original patch mostly failed to do). In addition this change lets us meet the spec's requirement to allow COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly behavior for constructs such as "foo::type COLLATE collation". To do this, pull collation information out of TypeName and put it in ColumnDef instead, thus reverting most of the collation-related changes in parse_type.c's API. I made one additional structural change, which was to use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd nodes. This provides enough room to get rid of the "transform" wart in AlterTableCmd too, since the ColumnDef can carry the USING expression easily enough. Also fix some other minor bugs that have crept in in the same areas, like failure to copy recently-added fields of ColumnDef in copyfuncs.c. While at it, document the formerly secret ability to specify a collation in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about what the default collation selection will be when COLLATE is omitted. BTW, the three-parameter form of format_type() should go away too, since it just contributes to the confusion in this area; but I'll do that in a separate patch.
* Don't allow CREATE TABLE AS to create a column with invalid collationPeter Eisentraut2011-03-04
| | | | | | | | | 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
* Support data-modifying commands (INSERT/UPDATE/DELETE) in WITH.Tom Lane2011-02-25
| | | | | | | | | | | | | | This patch implements data-modifying WITH queries according to the semantics that the updates all happen with the same command counter value, and in an unspecified order. Therefore one WITH clause can't see the effects of another, nor can the outer query see the effects other than through the RETURNING values. And attempts to do conflicting updates will have unpredictable results. We'll need to document all that. This commit just fixes the code; documentation updates are waiting on author. Marko Tiikkaja and Hitoshi Harada
* Avoid a few more SET DATA TYPE table rewrites.Robert Haas2011-02-14
| | | | | | | When the new type is an unconstrained domain over the old type, we don't need to rewrite the table. Noah Misch and Robert Haas
* Delete stray word from comment.Robert Haas2011-02-14
|
* DDL support for collationsPeter Eisentraut2011-02-12
| | | | | | | | | | | | | - collowner field - CREATE COLLATION - ALTER COLLATION - DROP COLLATION - COMMENT ON COLLATION - integration with extensions - pg_dump support for the above - dependency management - psql tab completion - psql \dO command
* Teach ALTER TABLE .. SET DATA TYPE to avoid some table rewrites.Robert Haas2011-02-12
| | | | | | | | | | | | | | | | | | | | | | | When the old type is binary coercible to the new type and the using clause does not change the column contents, we can avoid a full table rewrite, though any indexes on the affected columns will still need to be rebuilt. This applies, for example, when changing a varchar column to be of type text. The prior coding assumed that the set of operations that force a rewrite is identical to the set of operations that must be propagated to tables making use of the affected table's rowtype. This is no longer true: even though the tuples in those tables wouldn't need to be modified, the data type change invalidate indexes built using those composite type columns. Indexes on the table we're actually modifying can be invalidated too, of course, but the existing machinery is sufficient to handle that case. Along the way, add some debugging messages that make it possible to understand what operations ALTER TABLE is actually performing in these cases. Noah Misch and Robert Haas
* Tweak find_composite_type_dependencies API a bit more.Robert Haas2011-02-11
| | | | | | | | | | Per discussion with Noah Misch, the previous coding, introduced by my commit 65377e0b9c0e0397b1598b38b6a7fb8b6f740d39 on 2011-02-06, was really an abuse of RELKIND_COMPOSITE_TYPE, since the caller in typecmds.c is actually passing the name of a domain. So go back having a type name argument, but make the first argument a Relation rather than just a string so we can tell whether it's a table or a foreign table and emit the proper error message.
* Suppress some compiler warnings in recent commits.Tom Lane2011-02-08
| | | | | | | | | | | | | 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.
* Core support for "extensions", which are packages of SQL objects.Tom Lane2011-02-08
| | | | | | | | | | | | | 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
* Per-column collation supportPeter Eisentraut2011-02-08
| | | | | | | | This adds collation support for columns and domains, a COLLATE clause to override it per expression, and B-tree index support. Peter Eisentraut reviewed by Pavel Stehule, Itagaki Takahiro, Robert Haas, Noah Misch
* Extend ALTER TABLE to allow Foreign Keys to be added without initial validation.Simon Riggs2011-02-08
| | | | | | | | | FK constraints that are marked NOT VALID may later be VALIDATED, which uses an ShareUpdateExclusiveLock on constraint table and RowShareLock on referenced table. Significantly reduces lock strength and duration when adding FKs. New state visible from psql. Simon Riggs, with reviews from Marko Tiikkaja and Robert Haas
* Fix a comment for MergeAttributes.Itagaki Takahiro2011-02-07
| | | | We forgot to adjust it when we changed relistemp to relpersistence.
* Tighten ALTER FOREIGN TABLE .. SET DATA TYPE checks.Robert Haas2011-02-06
| | | | | | | If the foreign table's rowtype is being used as the type of a column in another table, we can't just up and change its data type. This was already checked for composite types and ordinary tables, but we previously failed to enforce it for foreign tables.
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-28 05:01:16 +0000