summaryrefslogtreecommitdiff
path: root/src/backend/commands/tablecmds.c
Commit message (Collapse)AuthorAgeFilesLines
...
* Create a GUC parameter temp_tablespaces that allows selection of theTom Lane2007-06-031-10/+10
| | | | | | | | | | tablespace(s) in which to store temp tables and temporary files. This is a list to allow spreading the load across multiple tablespaces (a random list element is chosen each time a temp object is to be created). Temp files are not stored in per-database pgsql_tmp/ directories anymore, but per-tablespace directories. Jaime Casanova and Albert Cervera, with review by Bernd Helmle and Tom Lane.
* Have CLUSTER advance the table's relfrozenxid. The new frozen point is theAlvaro Herrera2007-05-181-3/+8
| | | | | | | | | | | | | | | | FreezeXid introduced in a recent commit, so there isn't any data loss in this approach. Doing it causes ALTER TABLE (or rather, the forms of it that cause a full table rewrite) to be affected as well. In this case, the frozen point is RecentXmin, because after the rewrite all the tuples are relabeled with the rewriting transaction's Xid. TOAST tables are fixed automatically as well, as fallout of the way they were already being handled in the respective code paths. With this patch, there is no longer need to VACUUM tables for Xid wraparound purposes that have been cleaned up via TRUNCATE or CLUSTER.
* Have TRUNCATE advance the affected table's relfrozenxid to RecentXmin, toAlvaro Herrera2007-05-161-3/+3
| | | | | | | avoid a later needless VACUUM for Xid-wraparound purposes. We can do this since the table is known to be left empty, so no Xid remains on it. Per discussion.
* Get rid of the pg_shdepend entry for a TOAST table; it's unnecessary sinceTom Lane2007-05-141-3/+4
| | | | | | | there's an indirect dependency on the owner via the parent table. We were already handling indexes that way, but not toast tables for some reason. Saves a little catalog space and cuts down the verbosity of checkSharedDependencies reports.
* Fix the problem that creating a user-defined type named _foo, followed by oneTom Lane2007-05-121-5/+7
| | | | | | | | | | | named foo, would work but the other ordering would not. If a user-specified type or table name collides with an existing auto-generated array name, just rename the array type out of the way by prepending more underscores. This should not create any backward-compatibility issues, since the cases in which this will happen would have failed outright in prior releases. Also fix an oversight in the arrays-of-composites patch: ALTER TABLE RENAME renamed the table's rowtype but not its array type.
* Fix my oversight in enabling domains-of-domains: ALTER DOMAIN ADD CONSTRAINTTom Lane2007-05-111-15/+27
| | | | | | | | | | | | needs to check the new constraint against columns of derived domains too. Also, make it error out if the domain to be modified is used within any composite-type columns. Eventually we should support that case, but it seems a bit painful, and not suitable for a back-patch. For the moment just let the user know we can't do it. Backpatch to 8.2, which is the only released version that allows nested domains. Possibly the other part should be back-patched further.
* Support arrays of composite types, including the rowtypes of regular tablesTom Lane2007-05-111-6/+27
| | | | | | | | | | | | | | | and views (but not system catalogs, nor sequences or toast tables). Get rid of the hardwired convention that a type's array type is named exactly "_type", instead using a new column pg_type.typarray to provide the linkage. (It still will be named "_type", though, except in odd corner cases such as maximum-length type names.) Along the way, make tracking of owner and schema dependencies for types more uniform: a type directly created by the user has these dependencies, while a table rowtype or auto-generated array type does not have them, but depends on its parent object instead. David Fetter, Andrew Dunstan, Tom Lane
* Make CLUSTER MVCC-safe. Heikki LinnakangasTom Lane2007-04-081-29/+2
|
* Changes pg_trigger and extend pg_rewrite in order to allow triggers andJan Wieck2007-03-191-12/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | rules to be defined with different, per session controllable, behaviors for replication purposes. This will allow replication systems like Slony-I and, as has been stated on pgsql-hackers, other products to control the firing mechanism of triggers and rewrite rules without modifying the system catalog directly. The firing mechanisms are controlled by a new superuser-only GUC variable, session_replication_role, together with a change to pg_trigger.tgenabled and a new column pg_rewrite.ev_enabled. Both columns are a single char data type now (tgenabled was a bool before). The possible values in these attributes are: 'O' - Trigger/Rule fires when session_replication_role is "origin" (default) or "local". This is the default behavior. 'D' - Trigger/Rule is disabled and fires never 'A' - Trigger/Rule fires always regardless of the setting of session_replication_role 'R' - Trigger/Rule fires when session_replication_role is "replica" The GUC variable can only be changed as long as the system does not have any cached query plans. This will prevent changing the session role and accidentally executing stored procedures or functions that have plans cached that expand to the wrong query set due to differences in the rule firing semantics. The SQL syntax for changing a triggers/rules firing semantics is ALTER TABLE <tabname> <when> TRIGGER|RULE <name>; <when> ::= ENABLE | ENABLE ALWAYS | ENABLE REPLICA | DISABLE psql's \d command as well as pg_dump are extended in a backward compatible fashion. Jan
* First phase of plan-invalidation project: create a plan cache managementTom Lane2007-03-131-2/+8
| | | | | | | | | | | | | | | | module and teach PREPARE and protocol-level prepared statements to use it. In service of this, rearrange utility-statement processing so that parse analysis does not assume table schemas can't change before execution for utility statements (necessary because we don't attempt to re-acquire locks for utility statements when reusing a stored plan). This requires some refactoring of the ProcessUtility API, but it ends up cleaner anyway, for instance we can get rid of the QueryContext global. Still to do: fix up SPI and related code to use the plan cache; I'm tempted to try to make SQL functions use it too. Also, there are at least some aspects of system state that we want to ensure remain the same during a replan as in the original processing; search_path certainly ought to behave that way for instance, and perhaps there are others.
* Revert temp_tablespaces because of coding problems, per Tom.Bruce Momjian2007-03-061-5/+1
|
* Fix new RI operator selection code to do the right thing when working withTom Lane2007-02-161-19/+40
| | | | | | | an opclass for a generic type such as ANYARRAY. The original coding failed to check that PK and FK columns were of the same array type. Per discussion with Tom Dunstan. Also, make the code a shade more readable by not trying to economize on variables.
* Fix up foreign-key mechanism so that there is a sound semantic basis for theTom Lane2007-02-141-433/+130
| | | | | | | | | | | | | | | | | | | | | equality checks it applies, instead of a random dependence on whatever operators might be named "=". The equality operators will now be selected from the opfamily of the unique index that the FK constraint depends on to enforce uniqueness of the referenced columns; therefore they are certain to be consistent with that index's notion of equality. Among other things this should fix the problem noted awhile back that pg_dump may fail for foreign-key constraints on user-defined types when the required operators aren't in the search path. This also means that the former warning condition about "foreign key constraint will require costly sequential scans" is gone: if the comparison condition isn't indexable then we'll reject the constraint entirely. All per past discussions. Along the way, make the RI triggers look into pg_constraint for their information, instead of using pg_trigger.tgargs; and get rid of the always error-prone fixed-size string buffers in ri_triggers.c in favor of building up the RI queries in StringInfo buffers. initdb forced due to columns added to pg_constraint and pg_trigger.
* Repair failure to check that a table is still compatible with a previouslyTom Lane2007-02-021-7/+50
| | | | | | | | | | | | | | | | | | | | | | made query plan. Use of ALTER COLUMN TYPE creates a hazard for cached query plans: they could contain Vars that claim a column has a different type than it now has. Fix this by checking during plan startup that Vars at relation scan level match the current relation tuple descriptor. Since at that point we already have at least AccessShareLock, we can be sure the column type will not change underneath us later in the query. However, since a backend's locks do not conflict against itself, there is still a hole for an attacker to exploit: he could try to execute ALTER COLUMN TYPE while a query is in progress in the current backend. Seal that hole by rejecting ALTER TABLE whenever the target relation is already open in the current backend. This is a significant security hole: not only can one trivially crash the backend, but with appropriate misuse of pass-by-reference datatypes it is possible to read out arbitrary locations in the server process's memory, which could allow retrieving database content the user should not be able to see. Our thanks to Jeff Trout for the initial report. Security: CVE-2007-0556
* Add GUC temp_tablespaces to provide a default location for temporaryBruce Momjian2007-01-251-1/+5
| | | | | | objects. Jaime Casanova
* Properly detoast access to bytea field pg_trigger.tgargs. Old codeBruce Momjian2007-01-251-3/+2
| | | | | | might cause server crash. Backpatch to 8.2.X.
* Update CVS HEAD for 2007 copyright. Back branches are typically notBruce Momjian2007-01-051-2/+2
| | | | back-stamped for this.
* Clean up smgr.c/md.c APIs as per discussion a couple months ago. Instead ofTom Lane2007-01-031-2/+2
| | | | | | | | | | | | | | | | | | having md.c return a success/failure boolean to smgr.c, which was just going to elog anyway, let md.c issue the elog messages itself. This allows better error reporting, particularly in cases such as "short read" or "short write" which Peter was complaining of. Also, remove the kluge of allowing mdread() to return zeroes from a read-beyond-EOF: this is now an error condition except when InRecovery or zero_damaged_pages = true. (Hash indexes used to require that behavior, but no more.) Also, enforce that mdwrite() is to be used for rewriting existing blocks while mdextend() is to be used for extending the relation EOF. This restriction lets us get rid of the old ad-hoc defense against creating huge files by an accidental reference to a bogus block number: we'll only create new segments in mdextend() not mdwrite() or mdread(). (Again, when InRecovery we allow it anyway, since we need to allow updates of blocks that were later truncated away.) Also, clean up the original makeshift patch for bug #2737: move the responsibility for padding relation segments to full length into md.c.
* Support type modifiers for user-defined types, and pull most knowledgeTom Lane2006-12-301-12/+32
| | | | | | about typmod representation for standard types out into type-specific typmod I/O functions. Teodor Sigaev, with some editorialization by Tom Lane.
* Restructure operator classes to allow improved handling of cross-data-typeTom Lane2006-12-231-2/+2
| | | | | | | | | | | | | | | | cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
* Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.Tom Lane2006-10-131-165/+182
|
* Code review for LIKE INCLUDING CONSTRAINTS patch --- improve comments,Tom Lane2006-10-111-83/+114
| | | | don't cheat on the raw-vs-cooked status of a constraint.
* Message style improvementsPeter Eisentraut2006-10-061-4/+4
|
* pgindent run for 8.2.Bruce Momjian2006-10-041-82/+88
|
* Disallow TRUNCATE when there are any pending after-trigger events forTom Lane2006-09-041-1/+8
| | | | | | | the target relation(s). There might be some cases where we could discard the pending event instead, but for the moment a conservative approach seems sufficient. Per report from Markus Schiltknecht and subsequent discussion.
* Add the ability to create indexes 'concurrently', that is, withoutTom Lane2006-08-251-2/+3
| | | | | blocking concurrent writes to the table. Greg Stark, with a little help from Tom Lane.
* Fix all known problems with pg_dump's handling of serial sequencesTom Lane2006-08-211-50/+50
| | | | | | | | | | | | | | | | | | | | | by abandoning the idea that it should say SERIAL in the dump. Instead, dump serial sequences and column defaults just like regular ones. Add a new backend command ALTER SEQUENCE OWNED BY to let pg_dump recreate the sequence-to-column dependency that was formerly created "behind the scenes" by SERIAL. This restores SERIAL to being truly "just a macro" consisting of component operations that can be stated explicitly in SQL. Furthermore, the new command allows sequence ownership to be reassigned, so that old mistakes can be cleaned up. Also, downgrade the OWNED-BY dependency from INTERNAL to AUTO, since there is no longer any very compelling argument why the sequence couldn't be dropped while keeping the column. (This forces initdb, to be sure the right kinds of dependencies are in there.) Along the way, add checks to prevent ALTER OWNER or SET SCHEMA on an owned sequence; you can now only do this indirectly by changing the owning table's owner or schema. This is an oversight in previous releases, but probably not worth back-patching.
* Cause ALTER TABLE to perform ALTER COLUMN DROP DEFAULT operations duringTom Lane2006-08-031-2/+2
| | | | | | | | | the DROP pass rather than the ADD_CONSTR pass. On examining the code I think this was just an oversight rather than intentional, and it seems to satisfy the principle of least surprise better than the alternative solution that was discussed. Add an example to the ref page showing how to do ALTER TYPE and update the default in one command. Per gripe from Markus Bertheau that that wasn't possible.
* Change the relation_open protocol so that we obtain lock on a relationTom Lane2006-07-311-2/+5
| | | | | | | | | | | | (table or index) before trying to open its relcache entry. This fixes race conditions in which someone else commits a change to the relation's catalog entries while we are in process of doing relcache load. Problems of that ilk have been reported sporadically for years, but it was not really practical to fix until recently --- for instance, the recent addition of WAL-log support for in-place updates helped. Along the way, remove pg_am.amconcurrent: all AMs are now expected to support concurrent update.
* Change the bootstrap sequence so that toast tables for system catalogs areTom Lane2006-07-311-285/+5
| | | | | | | | | | created in the bootstrap phase proper, rather than added after-the-fact by initdb. This is cleaner than before because it allows us to retire the undocumented ALTER TABLE ... CREATE TOAST TABLE command, but the real reason I'm doing it is so that toast tables of shared catalogs will now have predetermined OIDs. This will allow a reasonably clean solution to the problem of locking tables before we load their relcache entries, to appear in a forthcoming patch.
* Remove 576 references of include files that were not needed.Bruce Momjian2006-07-141-2/+1
|
* Allow include files to compile own their own.Bruce Momjian2006-07-131-1/+3
| | | | | | | Strip unused include files out unused include files, and add needed includes to C files. The next step is to remove unused include files in C files.
* Alphabetically order reference to include files, "S"-"Z".Bruce Momjian2006-07-111-2/+2
|
* Fix ALTER TABLE to check pre-existing NOT NULL constraints when rewritingTom Lane2006-07-101-31/+38
| | | | | | a table. Otherwise a USING clause that yields NULL can leave the table violating its constraint (possibly there are other cases too). Per report from Alexander Pravking.
* Code review for FILLFACTOR patch. Change WITH grammar as per earlierTom Lane2006-07-031-54/+67
| | | | | | | | | | | | | | | | discussion (including making def_arg allow reserved words), add missed opt_definition for UNIQUE case. Put the reloptions support code in a less random place (I chose to make a new file access/common/reloptions.c). Eliminate header inclusion creep. Make the index options functions safely user-callable (seems like client apps might like to be able to test validity of options before trying to make an index). Reduce overhead for normal case with no options by allowing rd_options to be NULL. Fix some unmaintainably klugy code, including getting rid of Natts_pg_class_fixed at long last. Some stylistic cleanup too, and pay attention to keeping comments in sync with code. Documentation still needs work, though I did fix the omissions in catalogs.sgml and indexam.sgml.
* Do a pass of code review for the ALTER TABLE ADD INHERITS patch. KeepNeil Conway2006-07-021-133/+127
| | | | | | | | | the read lock we hold on the table's parent relation until commit. Update equalfuncs.c for the new field in AlterTableCmd. Various improvements to comments, variable names, and error reporting. There is room for further improvement here, but this is at least a step in the right direction.
* Add FILLFACTOR to CREATE INDEX.Bruce Momjian2006-07-021-28/+136
| | | | ITAGAKI Takahiro
* ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)Bruce Momjian2006-07-021-9/+509
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Open items: There were a few tangentially related issues that have come up that I think are TODOs. I'm likely to tackle one or two of these next so I'm interested in hearing feedback on them as well. . Constraints currently do not know anything about inheritance. Tom suggested adding a coninhcount and conislocal like attributes have to track their inheritance status. . Foreign key constraints currently do not get copied to new children (and therefore my code doesn't verify them). I don't think it would be hard to add them and treat them like CHECK constraints. . No constraints at all are copied to tables defined with LIKE. That makes it hard to use LIKE to define new partitions. The standard defines LIKE and specifically says it does not copy constraints. But the standard already has an option called INCLUDING DEFAULTS; we could always define a non-standard extension LIKE table INCLUDING CONSTRAINTS that gives the user the option to request a copy including constraints. . Personally, I think the whole attislocal thing is bunk. The decision about whether to drop a column from children tables or not is something that should be up to the user and trying to DWIM based on whether there was ever a local definition or the column was acquired purely through inheritance is hardly ever going to match up with user expectations. . And of course there's the whole unique and primary key constraint issue. I think to get any traction at all on this you have a prerequisite of a real partitioned table implementation where the system knows what the partition key is so it can recognize when it's a leading part of an index key. Greg Stark
* Revert patch, doesn't do what it should:Bruce Momjian2006-06-271-6/+1
| | | | | | * %Disallow changing default expression of a SERIAL column Dhanaraj M
* Add INCLUDING CONSTRAINTS to CREATE TABLE LIKE.Bruce Momjian2006-06-271-10/+49
| | | | Greg Stark
* Disallow changing/dropping default expression of a SERIAL columnBruce Momjian2006-06-271-1/+6
| | | | Dhanaraj M
* Fix problems with cached tuple descriptors disappearing while still in useTom Lane2006-06-161-1/+4
| | | | | | | | | | by creating a reference-count mechanism, similar to what we did a long time ago for catcache entries. The back branches have an ugly solution involving lots of extra copies, but this way is more efficient. Reference counting is only applied to tupdescs that are actually in caches --- there seems no need to use it for tupdescs that are generated in the executor, since they'll go away during plan shutdown by virtue of being in the per-query memory context. Neil Conway and Tom Lane
* Clean up code associated with updating pg_class statistics columnsTom Lane2006-05-101-9/+2
| | | | | | | | | | | (relpages/reltuples). To do this, create formal support in heapam.c for "overwrite" tuple updates (including xlog replay capability) and use that instead of the ad-hoc overwrites we'd been using in VACUUM and CREATE INDEX. Take the responsibility for updating stats during CREATE INDEX out of the individual index AMs, and do it where it belongs, in catalog/index.c. Aside from being more modular, this avoids having to update the same tuple twice in some paths through CREATE INDEX. It's probably not measurably faster, but for sure it's a lot cleaner than before.
* Revert patch pending more discussion:Bruce Momjian2006-04-301-6/+1
| | | | Disallow changing DEFAULT expression of a SERIAL column.
* Disallow changing DEFAULT expression of a SERIAL column.Bruce Momjian2006-04-291-1/+6
| | | | Dhanaraj M
* Improve parser so that we can show an error cursor position for errorsTom Lane2006-03-141-20/+13
| | | | | | | | | | | during parse analysis, not only errors detected in the flex/bison stages. This is per my earlier proposal. This commit includes all the basic infrastructure, but locations are only tracked and reported for errors involving column references, function calls, and operators. More could be done later but this seems like a good set to start with. I've also moved the ReportSyntaxErrorPosition logic out of psql and into libpq, which should make it available to more people --- even within psql this is an improvement because warnings weren't handled by ReportSyntaxErrorPosition.
* Update copyright for 2006. Update scripts.Bruce Momjian2006-03-051-2/+2
|
* Dept. of second thoughts: rejigger the TRUNCATE ... CASCADE patch so thatTom Lane2006-03-031-68/+63
| | | | | | | relations are still checked for permissions etc as soon as they are opened. The original form of the patch could hold exclusive lock for a long time on relations that the user doesn't even have permissions to access, let alone truncate.
* Add CASCADE option to TRUNCATE. Joachim WielandTom Lane2006-03-031-16/+74
|
* Fix ALTER COLUMN TYPE bug: it sometimes tried to drop UNIQUE or PRIMARY KEYTom Lane2006-01-301-9/+37
| | | | | constraints before FOREIGN KEY constraints that depended on them. Originally reported by Neil Conway on 29-Jun-2005. Patch by Nakano Yoshihisa.
View Lorry Controller Status