rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/src/backend/commands/tablecmds.c

10540 lines
316 KiB
C
Raw Normal View History

Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
/*-------------------------------------------------------------------------
*
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
* tablecmds.c
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
* Commands for creating and altering table structures and settings
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*
Update copyrights for 2013 Fully update git head, and update back branches in ./COPYRIGHT and legal.sgml files.
2013-01-01 23:15:01 +01:00
* Portions Copyright (c) 1996-2013, PostgreSQL Global Development Group
Add: * Portions Copyright (c) 1996-2000, PostgreSQL, Inc to all files copyright Regents of Berkeley. Man, that's a lot of files.
2000-01-26 06:58:53 +01:00
* Portions Copyright (c) 1994, Regents of the University of California
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*
*
* IDENTIFICATION
Remove cvs keywords from all files.
2010-09-20 22:08:53 +02:00
* src/backend/commands/tablecmds.c
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
*
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*-------------------------------------------------------------------------
*/
This patch... 1. Removes the unnecessary "#define AbcRegProcedure 123"'s from pg_proc.h. 2. Changes those #defines to use the names already defined in fmgr.h. 3. Forces the make of fmgr.h in backend/Makefile instead of having it made as a dependency in access/common/Makefile *hack*hack*hack* 4. Rearranged the #includes to a less helter-skelter arrangement, also changing <file.h> to "file.h" to signify a non-system header. 5. Removed "pg_proc.h" from files where its only purpose was for the #defines removed in item #1. 6. Added "fmgr.h" to each file changed for completeness sake. Turns out that #6 was not necessary for some files because fmgr.h was being included in a roundabout way SIX levels deep by the first include. "access/genam.h" ->"access/relscan.h" ->"utils/rel.h" ->"access/strat.h" ->"access/skey.h" ->"fmgr.h" So adding fmgr.h really didn't add anything to the compile, hopefully just made it clearer to the programmer. S Darren.
1998-04-27 06:08:07 +02:00
#include "postgres.h"
has_table_privilege functions from Joe Conway (with some kibitzing from Tom Lane). For the moment, only the OID/name variants are provided. I didn't force initdb, but the additions to the 'privileges' regress test won't pass until you do one.
2001-06-14 03:09:22 +02:00
#include "access/genam.h"
Improve concurrency of foreign key locking This patch introduces two additional lock modes for tuples: "SELECT FOR KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each other, in contrast with already existing "SELECT FOR SHARE" and "SELECT FOR UPDATE". UPDATE commands that do not modify the values stored in the columns that are part of the key of the tuple now grab a SELECT FOR NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently with tuple locks of the FOR KEY SHARE variety. Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this means the concurrency improvement applies to them, which is the whole point of this patch. The added tuple lock semantics require some rejiggering of the multixact module, so that the locking level that each transaction is holding can be stored alongside its Xid. Also, multixacts now need to persist across server restarts and crashes, because they can now represent not only tuple locks, but also tuple updates. This means we need more careful tracking of lifetime of pg_multixact SLRU files; since they now persist longer, we require more infrastructure to figure out when they can be removed. pg_upgrade also needs to be careful to copy pg_multixact files over from the old server to the new, or at least part of multixact.c state, depending on the versions of the old and new servers. Tuple time qualification rules (HeapTupleSatisfies routines) need to be careful not to consider tuples with the "is multi" infomask bit set as being only locked; they might need to look up MultiXact values (i.e. possibly do pg_multixact I/O) to find out the Xid that updated a tuple, whereas they previously were assured to only use information readily available from the tuple header. This is considered acceptable, because the extra I/O would involve cases that would previously cause some commands to block waiting for concurrent transactions to finish. Another important change is the fact that locking tuples that have previously been updated causes the future versions to be marked as locked, too; this is essential for correctness of foreign key checks. This causes additional WAL-logging, also (there was previously a single WAL record for a locked tuple; now there are as many as updated copies of the tuple there exist.) With all this in place, contention related to tuples being checked by foreign key rules should be much reduced. As a bonus, the old behavior that a subtransaction grabbing a stronger tuple lock than the parent (sub)transaction held on a given tuple and later aborting caused the weaker lock to be lost, has been fixed. Many new spec files were added for isolation tester framework, to ensure overall behavior is sane. There's probably room for several more tests. There were several reviewers of this patch; in particular, Noah Misch and Andres Freund spent considerable time in it. Original idea for the patch came from Simon Riggs, after a problem report by Joel Jacobson. Most code is from me, with contributions from Marti Raudsepp, Alexander Shulgin, Noah Misch and Andres Freund. This patch was discussed in several pgsql-hackers threads; the most important start at the following message-ids: AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com 1290721684-sup-3951@alvh.no-ip.org 1294953201-sup-2099@alvh.no-ip.org 1320343602-sup-2290@alvh.no-ip.org 1339690386-sup-8927@alvh.no-ip.org 4FE5FF020200002500048A3D@gw.wicourts.gov 4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
#include "access/heapam.h"
Split heapam_xlog.h from heapam.h The heapam XLog functions are used by other modules, not all of which are interested in the rest of the heapam API. With this, we let them get just the XLog stuff in which they are interested and not pollute them with unrelated includes. Also, since heapam.h no longer requires xlog.h, many files that do include heapam.h no longer get xlog.h automatically, including a few headers. This is useful because heapam.h is getting pulled in by execnodes.h, which is in turn included by a lot of files.
2012-08-29 01:02:00 +02:00
#include "access/heapam_xlog.h"
Improve concurrency of foreign key locking This patch introduces two additional lock modes for tuples: "SELECT FOR KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each other, in contrast with already existing "SELECT FOR SHARE" and "SELECT FOR UPDATE". UPDATE commands that do not modify the values stored in the columns that are part of the key of the tuple now grab a SELECT FOR NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently with tuple locks of the FOR KEY SHARE variety. Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this means the concurrency improvement applies to them, which is the whole point of this patch. The added tuple lock semantics require some rejiggering of the multixact module, so that the locking level that each transaction is holding can be stored alongside its Xid. Also, multixacts now need to persist across server restarts and crashes, because they can now represent not only tuple locks, but also tuple updates. This means we need more careful tracking of lifetime of pg_multixact SLRU files; since they now persist longer, we require more infrastructure to figure out when they can be removed. pg_upgrade also needs to be careful to copy pg_multixact files over from the old server to the new, or at least part of multixact.c state, depending on the versions of the old and new servers. Tuple time qualification rules (HeapTupleSatisfies routines) need to be careful not to consider tuples with the "is multi" infomask bit set as being only locked; they might need to look up MultiXact values (i.e. possibly do pg_multixact I/O) to find out the Xid that updated a tuple, whereas they previously were assured to only use information readily available from the tuple header. This is considered acceptable, because the extra I/O would involve cases that would previously cause some commands to block waiting for concurrent transactions to finish. Another important change is the fact that locking tuples that have previously been updated causes the future versions to be marked as locked, too; this is essential for correctness of foreign key checks. This causes additional WAL-logging, also (there was previously a single WAL record for a locked tuple; now there are as many as updated copies of the tuple there exist.) With all this in place, contention related to tuples being checked by foreign key rules should be much reduced. As a bonus, the old behavior that a subtransaction grabbing a stronger tuple lock than the parent (sub)transaction held on a given tuple and later aborting caused the weaker lock to be lost, has been fixed. Many new spec files were added for isolation tester framework, to ensure overall behavior is sane. There's probably room for several more tests. There were several reviewers of this patch; in particular, Noah Misch and Andres Freund spent considerable time in it. Original idea for the patch came from Simon Riggs, after a problem report by Joel Jacobson. Most code is from me, with contributions from Marti Raudsepp, Alexander Shulgin, Noah Misch and Andres Freund. This patch was discussed in several pgsql-hackers threads; the most important start at the following message-ids: AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com 1290721684-sup-3951@alvh.no-ip.org 1294953201-sup-2099@alvh.no-ip.org 1320343602-sup-2290@alvh.no-ip.org 1339690386-sup-8927@alvh.no-ip.org 4FE5FF020200002500048A3D@gw.wicourts.gov 4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
#include "access/multixact.h"
Code review for FILLFACTOR patch. Change WITH grammar as per earlier 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.
2006-07-04 00:45:41 +02:00
#include "access/reloptions.h"
Improve our #include situation by moving pointer types away from the corresponding struct definitions. This allows other headers to avoid including certain highly-loaded headers such as rel.h and relscan.h, instead using just relcache.h, heapam.h or genam.h, which are more lightweight and thus cause less unnecessary dependencies.
2008-06-19 02:46:06 +02:00
#include "access/relscan.h"
Restructure some header files a bit, in particular heapam.h, by removing some unnecessary #include lines in it. Also, move some tuple routine prototypes and macros to htup.h, which allows removal of heapam.h inclusion from some .c files. For this to work, a new header file access/sysattr.h needed to be created, initially containing attribute numbers of system columns, for pg_dump usage. While at it, make contrib ltree, intarray and hstore header files more consistent with our header style.
2008-05-12 02:00:54 +02:00
#include "access/sysattr.h"
Allow include files to compile own their own. 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.
2006-07-13 18:49:20 +02:00
#include "access/xact.h"
This patch... 1. Removes the unnecessary "#define AbcRegProcedure 123"'s from pg_proc.h. 2. Changes those #defines to use the names already defined in fmgr.h. 3. Forces the make of fmgr.h in backend/Makefile instead of having it made as a dependency in access/common/Makefile *hack*hack*hack* 4. Rearranged the #includes to a less helter-skelter arrangement, also changing <file.h> to "file.h" to signify a non-system header. 5. Removed "pg_proc.h" from files where its only purpose was for the #defines removed in item #1. 6. Added "fmgr.h" to each file changed for completeness sake. Turns out that #6 was not necessary for some files because fmgr.h was being included in a roundabout way SIX levels deep by the first include. "access/genam.h" ->"access/relscan.h" ->"utils/rel.h" ->"access/strat.h" ->"access/skey.h" ->"fmgr.h" So adding fmgr.h really didn't add anything to the compile, hopefully just made it clearer to the programmer. S Darren.
1998-04-27 06:08:07 +02:00
#include "catalog/catalog.h"
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
#include "catalog/dependency.h"
has_table_privilege functions from Joe Conway (with some kibitzing from Tom Lane). For the moment, only the OID/name variants are provided. I didn't force initdb, but the additions to the 'privileges' regress test won't pass until you do one.
2001-06-14 03:09:22 +02:00
#include "catalog/heap.h"
Make toast-table creation and deletion work somewhat reliably. Don't go through pg_exec_query_dest(), but directly to the execution routines. Also, extend parameter lists so that there's no need to change the global setting of allowSystemTableMods, a hack that was certain to cause trouble in the event of any error.
2000-07-04 08:11:54 +02:00
#include "catalog/index.h"
Final cleanup.
1999-07-16 07:00:38 +02:00
#include "catalog/indexing.h"
pg_class has a relnamespace column. You can create and access tables in schemas other than the system namespace; however, there's no search path yet, and not all operations work yet on tables outside the system namespace.
2002-03-26 20:17:02 +01:00
#include "catalog/namespace.h"
Object access hook framework, with post-creation hook. After a SQL object is created, we provide an opportunity for security or logging plugins to get control; for example, a security label provider could use this to assign an initial security label to newly created objects. The basic infrastructure is (hopefully) reusable for other types of events that might require similar treatment. KaiGai Kohei, with minor adjustments.
2010-11-25 17:48:49 +01:00
#include "catalog/objectaccess.h"
DDL support for collations - 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
2011-02-12 14:54:13 +01:00
#include "catalog/pg_collation.h"
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
#include "catalog/pg_constraint.h"
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
#include "catalog/pg_depend.h"
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
#include "catalog/pg_foreign_table.h"
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
#include "catalog/pg_inherits.h"
Modify find_inheritance_children() and find_all_inheritors() to add the ability to lock relations as they scan pg_inherits, and to ignore any relations that have disappeared by the time we get lock on them. This makes uses of these functions safe against concurrent DROP operations on child tables: we will effectively ignore any just-dropped child, rather than possibly throwing an error as in recent bug report from Thomas Johansson (and similar past complaints). The behavior should not change otherwise, since the code was acquiring those same locks anyway, just a little bit later. An exception is LockTableCommand(), which is still behaving unsafely; but that seems to require some more discussion before we change it.
2009-05-12 05:11:02 +02:00
#include "catalog/pg_inherits_fn.h"
Create the pg_namespace system catalog. Doesn't do much yet, but it's there and CREATE SCHEMA will make entries in it...
2002-03-22 22:34:44 +01:00
#include "catalog/pg_namespace.h"
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
#include "catalog/pg_opclass.h"
Remove hack in pg_tablespace_aclmask() that disallowed permissions on pg_global even to superusers, and replace it with checks in various other places to complain about invalid uses of pg_global. This ends up being a bit more code but it allows a more specific error message to be given, and it un-breaks pg_tablespace_size() on pg_global. Per discussion.
2007-10-12 20:55:12 +02:00
#include "catalog/pg_tablespace.h"
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
#include "catalog/pg_trigger.h"
has_table_privilege functions from Joe Conway (with some kibitzing from Tom Lane). For the moment, only the OID/name variants are provided. I didn't force initdb, but the additions to the 'privileges' regress test won't pass until you do one.
2001-06-14 03:09:22 +02:00
#include "catalog/pg_type.h"
Reduce the need for frontend programs to include "postgres.h" by refactoring inclusions in src/include/catalog/*.h files. The main idea here is to push function declarations for src/backend/catalog/*.c files into separate headers, rather than sticking them into the corresponding catalog definition file as has been done in the past. This commit only carries out that idea fully for pg_proc, pg_type and pg_conversion, but that's enough for the moment --- if pg_list.h ever becomes unsafe for frontend code to include, we'll need to work a bit more. Zdenek Kotala
2008-03-27 04:57:34 +01:00
#include "catalog/pg_type_fn.h"
Rethink the way FSM truncation works. Instead of WAL-logging FSM truncations in FSM code, call FreeSpaceMapTruncateRel from smgr_redo. To make that cleaner from modularity point of view, move the WAL-logging one level up to RelationTruncate, and move RelationTruncate and all the related WAL-logging to new src/backend/catalog/storage.c file. Introduce new RelationCreateStorage and RelationDropStorage functions that are used instead of calling smgrcreate/smgrscheduleunlink directly. Move the pending rel deletion stuff from smgrcreate/smgrscheduleunlink to the new functions. This leaves smgr.c as a thin wrapper around md.c; all the transactional stuff is now in storage.c. This will make it easier to add new forks with similar truncation logic, like the visibility map.
2008-11-19 11:34:52 +01:00
#include "catalog/storage.h"
Change the bootstrap sequence so that toast tables for system catalogs are 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.
2006-07-31 03:16:38 +02:00
#include "catalog/toasting.h"
Transaction safe Truncate Rod Taylor
2002-11-23 05:05:52 +01:00
#include "commands/cluster.h"
CREATE LIKE INCLUDING COMMENTS and STORAGE, and INCLUDING ALL shortcut. Itagaki Takahiro.
2009-10-12 21:49:24 +02:00
#include "commands/comment.h"
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
#include "commands/defrem.h"
Add a RESTART (without parameter) option to ALTER SEQUENCE, allowing a sequence to be reset to its original starting value. This requires adding the original start value to the set of parameters (columns) of a sequence object, which is a user-visible change with potential compatibility implications; it also forces initdb. Also add hopefully-SQL-compatible RESTART/CONTINUE IDENTITY options to TRUNCATE TABLE. RESTART IDENTITY executes ALTER SEQUENCE RESTART for all sequences "owned by" any of the truncated relations. CONTINUE IDENTITY is a no-op option. Zoltan Boszormenyi
2008-05-17 01:36:05 +02:00
#include "commands/sequence.h"
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
#include "commands/tablecmds.h"
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
#include "commands/tablespace.h"
has_table_privilege functions from Joe Conway (with some kibitzing from Tom Lane). For the moment, only the OID/name variants are provided. I didn't force initdb, but the additions to the 'privileges' regress test won't pass until you do one.
2001-06-14 03:09:22 +02:00
#include "commands/trigger.h"
Fix ALTER TABLE ADD COLUMN so that constraints of domain types are enforced properly when there is no explicit default value for the new column. Per report from Craig Perras.
2005-01-25 00:21:57 +01:00
#include "commands/typecmds.h"
Fix checksums for CLUSTER, VACUUM FULL etc. In CLUSTER, VACUUM FULL and ALTER TABLE SET TABLESPACE I erroneously set checksum before log_newpage, which sets the LSN and invalidates the checksum. So set checksum immediately *after* log_newpage. Bug report Fujii Masao, Fix and patch by Jeff Davis
2013-04-07 23:16:51 +02:00
#include "common/relpath.h"
has_table_privilege functions from Joe Conway (with some kibitzing from Tom Lane). For the moment, only the OID/name variants are provided. I didn't force initdb, but the additions to the 'privileges' regress test won't pass until you do one.
2001-06-14 03:09:22 +02:00
#include "executor/executor.h"
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
#include "foreign/foreign.h"
Final cleanup.
1999-07-16 07:00:38 +02:00
#include "miscadmin.h"
A little further progress on schemas: push down RangeVars into addRangeTableEntry calls. Remove relname field from RTEs, since it will no longer be a useful unique identifier of relations; we want to encourage people to rely on the relation OID instead. Further work on dumping qual expressions in EXPLAIN, too.
2002-03-22 03:56:37 +01:00
#include "nodes/makefuncs.h"
Move exprType(), exprTypmod(), expression_tree_walker(), and related routines into nodes/nodeFuncs, so as to reduce wanton cross-subsystem #includes inside the backend. There's probably more that should be done along this line, but this is a start anyway.
2008-08-26 00:42:34 +02:00
#include "nodes/nodeFuncs.h"
Add ALTER VIEW ... RENAME TO, and a RENAME TO clause to ALTER SEQUENCE. Sequences and views could previously be renamed using ALTER TABLE, but this was a repeated source of confusion for users. Update the docs, and psql tab completion. Patch from David Fetter; various minor fixes by myself.
2007-07-03 03:30:37 +02:00
#include "nodes/parsenodes.h"
has_table_privilege functions from Joe Conway (with some kibitzing from Tom Lane). For the moment, only the OID/name variants are provided. I didn't force initdb, but the additions to the 'privileges' regress test won't pass until you do one.
2001-06-14 03:09:22 +02:00
#include "optimizer/clauses.h"
Add notion of a "transform function" that can simplify function calls. 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
2011-06-22 04:15:24 +02:00
#include "optimizer/planner.h"
Fix a minor bug introduced by the recent CREATE TABLE AS / WITH OIDS patch: a 3-value enum was mistakenly assigned directly to a 'bool' in transformCreateStmt(). Along the way, change makeObjectName() to be static, as it isn't used outside analyze.c
2004-01-23 03:13:12 +01:00
#include "parser/parse_clause.h"
Get rid of long-since-vestigial Iter node type, in favor of adding a returns-set boolean field in Func and Oper nodes. This allows cleaner, more reliable tests for expressions returning sets in the planner and parser. For example, a WHERE clause returning a set is now detected and complained of in the parser, not only at runtime.
2002-05-13 01:43:04 +02:00
#include "parser/parse_coerce.h"
Revise collation derivation method and expression-tree representation. 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.
2011-03-20 01:29:08 +01:00
#include "parser/parse_collate.h"
This should be a slighly more complete patch for commands/command.c AlterTableAddConstraint. The major changes from the last patch are that it should hopefully check for references to temp tables (not in the shadow case, but at defination time) from permanent tables in foreign keys and refuse them and that it doesn't allow the table(s) being constrained to be views (because those cases don't currently work). Stephan SzaboThis should be a slighly more complete patch for commands/command.c AlterTableAddConstraint. The major changes from the last patch are that it should hopefully check for references to temp tables (not in the shadow case, but at defination time) from permanent tables in foreign keys and refuse them and that it doesn't allow the table(s) being constrained to be views (because those cases don't currently work). Stephan Szabo
2000-07-15 14:37:14 +02:00
#include "parser/parse_expr.h"
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
#include "parser/parse_oper.h"
has_table_privilege functions from Joe Conway (with some kibitzing from Tom Lane). For the moment, only the OID/name variants are provided. I didn't force initdb, but the additions to the 'privileges' regress test won't pass until you do one.
2001-06-14 03:09:22 +02:00
#include "parser/parse_relation.h"
pg_type has a typnamespace column; system now supports creating types in different namespaces. Also, cleanup work on relation namespace support: drop, alter, rename commands work for tables in non-default namespaces.
2002-03-29 20:06:29 +01:00
#include "parser/parse_type.h"
Separate parse-analysis for utility commands out of parser/analyze.c (which now deals only in optimizable statements), and put that code into a new file parser/parse_utilcmd.c. This helps clarify and enforce the design rule that utility statements shouldn't be processed during the regular parse analysis phase; all interpretation of their meaning should happen after they are given to ProcessUtility to execute. (We need this because we don't retain any locks for a utility statement that's in a plan cache, nor have any way to detect that it's stale.) We are also able to simplify the API for parse_analyze() and related routines, because they will now always return exactly one Query structure. In passing, fix bug #3403 concerning trying to add a serial column to an existing temp table (this is largely Heikki's work, but we needed all that restructuring to make it safe).
2007-06-24 00:12:52 +02:00
#include "parser/parse_utilcmd.h"
Alphabetically order reference to include files, "S"-"Z".
2006-07-11 20:26:11 +02:00
#include "parser/parser.h"
Changes pg_trigger and extend pg_rewrite in order to allow triggers and 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
2007-03-20 00:38:32 +01:00
#include "rewrite/rewriteDefine.h"
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
#include "rewrite/rewriteHandler.h"
Prevent CREATE TABLE LIKE/INHERITS from (mis) copying whole-row Vars. If a CHECK constraint or index definition contained a whole-row Var (that is, "table.*"), an attempt to copy that definition via CREATE TABLE LIKE or table inheritance produced incorrect results: the copied Var still claimed to have the rowtype of the source table, rather than the created table. For the LIKE case, it seems reasonable to just throw error for this situation, since the point of LIKE is that the new table is not permanently coupled to the old, so there's no reason to assume its rowtype will stay compatible. In the inheritance case, we should ideally allow such constraints, but doing so will require nontrivial refactoring of CREATE TABLE processing (because we'd need to know the OID of the new table's rowtype before we adjust inherited CHECK constraints). In view of the lack of previous complaints, that doesn't seem worth the risk in a back-patched bug fix, so just make it throw error for the inheritance case as well. Along the way, replace change_varattnos_of_a_node() with a more robust function map_variable_attnos(), which is capable of being extended to handle insertion of ConvertRowtypeExpr whenever we get around to fixing the inheritance case nicely, and in the meantime it returns a failure indication to the caller so that a helpful message with some context can be thrown. Also, this code will do the right thing with subselects (if we ever allow them in CHECK or indexes), and it range-checks varattnos before using them to index into the map array. Per report from Sergey Konoplev. Back-patch to all supported branches.
2012-06-30 22:43:50 +02:00
#include "rewrite/rewriteManip.h"
Restructure some header files a bit, in particular heapam.h, by removing some unnecessary #include lines in it. Also, move some tuple routine prototypes and macros to htup.h, which allows removal of heapam.h inclusion from some .c files. For this to work, a new header file access/sysattr.h needed to be created, initially containing attribute numbers of system columns, for pg_dump usage. While at it, make contrib ltree, intarray and hstore header files more consistent with our header style.
2008-05-12 02:00:54 +02:00
#include "storage/bufmgr.h"
Refactor the handling of the various DropStmt variants so that when multiple objects are specified, we drop them all in a single performMultipleDeletions call. This makes the RESTRICT/CASCADE checks more relaxed: it's not counted as a cascade if one of the later objects has a dependency on an earlier one. NOTICE messages about such cases go away, too. In passing, fix the permissions check for DROP CONVERSION, which for some reason was never made role-aware, and omitted the namespace-owner exemption too. Alex Hunsaker, with further fiddling by me.
2008-06-14 20:04:34 +02:00
#include "storage/lmgr.h"
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
#include "storage/lock.h"
Make DDL operations play nicely with Serializable Snapshot Isolation. 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.
2011-06-08 12:47:21 +02:00
#include "storage/predicate.h"
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
#include "storage/smgr.h"
has_table_privilege functions from Joe Conway (with some kibitzing from Tom Lane). For the moment, only the OID/name variants are provided. I didn't force initdb, but the additions to the 'privileges' regress test won't pass until you do one.
2001-06-14 03:09:22 +02:00
#include "utils/acl.h"
#include "utils/builtins.h"
#include "utils/fmgroids.h"
Adjust setRelhassubclassInRelation() to not perform actual heap_update when the pg_class.relhassubclass value is already correct. This should avoid most cases of the 'tuple concurrently updated' problem that Robert Creager recently complained about. Also remove a bunch of dead code in StoreCatalogInheritance() --- it was still computing the complete list of direct and indirect inheritance ancestors, though that list has not been needed since we got rid of the pg_ipl catalog.
2003-10-13 22:02:52 +02:00
#include "utils/inval.h"
has_table_privilege functions from Joe Conway (with some kibitzing from Tom Lane). For the moment, only the OID/name variants are provided. I didn't force initdb, but the additions to the 'privileges' regress test won't pass until you do one.
2001-06-14 03:09:22 +02:00
#include "utils/lsyscache.h"
For some reason access/tupmacs.h has been #including utils/memutils.h, which is neither needed by nor related to that header. Remove the bogus inclusion and instead include the header in those C files that actually need it. Also fix unnecessary inclusions and bad inclusion order in tsearch2 files.
2005-05-06 19:24:55 +02:00
#include "utils/memutils.h"
This is mostly the same as an earlier patch I didn't hear anything about, but which would have broken with the function manager changes anyway. Well, this patch checks that a unique constraint of some form (unique or pk) is on the referenced columns of an FK constraint and that the columns in the referencing table exist at creation time. The former is to move closer to SQL compatibility and the latter is in answer to a bug report. I also added a basic check of this functionality to the alter table and foreign key regression tests. Stephan Szabo sszabo@bigpanda.com
2000-08-29 06:20:47 +02:00
#include "utils/relcache.h"
Rename snapmgmt.c/h to snapmgr.c/h, for consistency with other files. Per complaint from Tom Lane.
2008-03-26 19:48:59 +01:00
#include "utils/snapmgr.h"
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
#include "utils/syscache.h"
Move the HTSU_Result enum definition into snapshot.h, to avoid including tqual.h into heapam.h. This makes all inclusion of tqual.h explicit. I also sorted alphabetically the includes on some source files.
2008-03-26 22:10:39 +01:00
#include "utils/tqual.h"
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
#include "utils/typcache.h"
Reimplement temp tables using schemas. The temp table map is history; temp table entries in pg_class have the names the user would expect.
2002-03-31 08:26:32 +02:00
Code review for FILLFACTOR patch. Change WITH grammar as per earlier 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.
2006-07-04 00:45:41 +02:00
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
/*
* ON COMMIT action list
*/
typedef struct OnCommitItem
{
pgindent run.
2003-08-04 02:43:34 +02:00
Oid relid; /* relid of relation */
OnCommitAction oncommit; /* what to do at end of xact */
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
/*
Restructure subtransaction handling to reduce resource consumption, as per recent discussions. Invent SubTransactionIds that are managed like CommandIds (ie, counter is reset at start of each top transaction), and use these instead of TransactionIds to keep track of subtransaction status in those modules that need it. This means that a subtransaction does not need an XID unless it actually inserts/modifies rows in the database. Accordingly, don't assign it an XID nor take a lock on the XID until it tries to do that. This saves a lot of overhead for subtransactions that are only used for error recovery (eg plpgsql exceptions). Also, arrange to release a subtransaction's XID lock as soon as the subtransaction exits, in both the commit and abort cases. This avoids holding many unique locks after a long series of subtransactions. The price is some additional overhead in XactLockTableWait, but that seems acceptable. Finally, restructure the state machine in xact.c to have a more orthogonal set of states for subtransactions.
2004-09-16 18:58:44 +02:00
* If this entry was created during the current transaction,
* creating_subid is the ID of the creating subxact; if created in a prior
* transaction, creating_subid is zero. If deleted during the current
* transaction, deleting_subid is the ID of the deleting subxact; if no
* deletion request is pending, deleting_subid is zero.
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
*/
Restructure subtransaction handling to reduce resource consumption, as per recent discussions. Invent SubTransactionIds that are managed like CommandIds (ie, counter is reset at start of each top transaction), and use these instead of TransactionIds to keep track of subtransaction status in those modules that need it. This means that a subtransaction does not need an XID unless it actually inserts/modifies rows in the database. Accordingly, don't assign it an XID nor take a lock on the XID until it tries to do that. This saves a lot of overhead for subtransactions that are only used for error recovery (eg plpgsql exceptions). Also, arrange to release a subtransaction's XID lock as soon as the subtransaction exits, in both the commit and abort cases. This avoids holding many unique locks after a long series of subtransactions. The price is some additional overhead in XactLockTableWait, but that seems acceptable. Finally, restructure the state machine in xact.c to have a more orthogonal set of states for subtransactions.
2004-09-16 18:58:44 +02:00
SubTransactionId creating_subid;
SubTransactionId deleting_subid;
Another pgindent run with updated typedefs.
2003-08-08 23:42:59 +02:00
} OnCommitItem;
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
static List *on_commits = NIL;
Included all yacc and lex files into the distribution.
2000-01-16 21:05:00 +01:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* State information for ALTER TABLE
*
* The pending-work queue for an ALTER TABLE is a List of AlteredTableInfo
* structs, one for each table modified by the operation (the named table
* plus any child tables that are affected). We save lists of subcommands
* to apply to this table (possibly modified by parse transformation steps);
* these lists will be executed in Phase 2. If a Phase 3 step is needed,
* necessary information is stored in the constraints and newvals lists.
*
* Phase 2 is divided into multiple passes; subcommands are executed in
* a pass determined by subcommand type.
*/
#define AT_PASS_DROP 0 /* DROP (all flavors) */
#define AT_PASS_ALTER_TYPE 1 /* ALTER COLUMN TYPE */
#define AT_PASS_OLD_INDEX 2 /* re-add existing indexes */
#define AT_PASS_OLD_CONSTR 3 /* re-add existing constraints */
#define AT_PASS_COL_ATTRS 4 /* set other column attributes */
/* We could support a RENAME COLUMN pass here, but not currently used */
#define AT_PASS_ADD_COL 5 /* ADD COLUMN */
#define AT_PASS_ADD_INDEX 6 /* ADD indexes */
#define AT_PASS_ADD_CONSTR 7 /* ADD constraints, defaults */
#define AT_PASS_MISC 8 /* other stuff */
#define AT_NUM_PASSES 9
typedef struct AlteredTableInfo
{
/* Information saved before any work commences: */
Oid relid; /* Relation to work on */
Fix a couple of oversights in new ALTER TABLE code that broke ALTER SET STATISTICS for functional indexes.
2004-05-09 00:46:29 +02:00
char relkind; /* Its relkind */
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
TupleDesc oldDesc; /* Pre-modification tuple descriptor */
/* Information saved by Phase 1 for Phase 2: */
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
List *subcmds[AT_NUM_PASSES]; /* Lists of AlterTableCmd */
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Information saved by Phases 1/2 for Phase 3: */
List *constraints; /* List of NewConstraint */
List *newvals; /* List of NewColumnValue */
Fix ALTER TABLE to check pre-existing NOT NULL constraints when rewriting 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.
2006-07-11 00:10:39 +02:00
bool new_notnull; /* T if we added new NOT NULL constraints */
Delete stray word from comment.
2011-02-15 04:37:37 +01:00
bool rewrite; /* T if a rewrite is forced */
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
Oid newTableSpace; /* new tablespace; 0 means no change */
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Objects to rebuild after completing ALTER TYPE operations */
List *changedConstraintOids; /* OIDs of constraints to rebuild */
List *changedConstraintDefs; /* string definitions of same */
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
List *changedIndexOids; /* OIDs of indexes to rebuild */
List *changedIndexDefs; /* string definitions of same */
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
} AlteredTableInfo;
/* Struct describing one new constraint to check in Phase 3 scan */
Fix ALTER TABLE to check pre-existing NOT NULL constraints when rewriting 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.
2006-07-11 00:10:39 +02:00
/* Note: new NOT NULL constraints are handled elsewhere */
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
typedef struct NewConstraint
{
char *name; /* Constraint name, or NULL if none */
Fix ALTER TABLE to check pre-existing NOT NULL constraints when rewriting 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.
2006-07-11 00:10:39 +02:00
ConstrType contype; /* CHECK or FOREIGN */
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Oid refrelid; /* PK rel, if FOREIGN */
Add system catalog columns pg_constraint.conindid and pg_trigger.tgconstrindid. conindid is the index supporting a constraint. We can use this not only for unique/primary-key constraints, but also foreign-key constraints, which depend on the unique index that constrains the referenced columns. tgconstrindid is just copied from the constraint's conindid field, or is zero for triggers not associated with constraints. This is mainly intended as infrastructure for upcoming patches, but it has some virtue in itself, since it exposes a relationship that you formerly had to grovel in pg_depend to determine. I simplified one information_schema view accordingly. (There is a pg_dump query that could also use conindid, but I left it alone because it wasn't clear it'd get any faster.)
2009-07-28 04:56:31 +02:00
Oid refindid; /* OID of PK's index, if FOREIGN */
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
Oid conid; /* OID of pg_constraint entry, if FOREIGN */
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
Node *qual; /* Check expr or CONSTR_FOREIGN Constraint */
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
List *qualstate; /* Execution state for CHECK */
} NewConstraint;
/*
* Struct describing one new column value that needs to be computed during
* Phase 3 copy (this could be either a new column with a non-null default, or
* a column that we're changing the type of). Columns without such an entry
* are just copied from the old table during ATRewriteTable. Note that the
* expr is an expression over *old* table values.
*/
typedef struct NewColumnValue
{
AttrNumber attnum; /* which column */
Expr *expr; /* expression to compute */
ExprState *exprstate; /* execution state */
} NewColumnValue;
Refactor the handling of the various DropStmt variants so that when multiple objects are specified, we drop them all in a single performMultipleDeletions call. This makes the RESTRICT/CASCADE checks more relaxed: it's not counted as a cascade if one of the later objects has a dependency on an earlier one. NOTICE messages about such cases go away, too. In passing, fix the permissions check for DROP CONVERSION, which for some reason was never made role-aware, and omitted the namespace-owner exemption too. Alex Hunsaker, with further fiddling by me.
2008-06-14 20:04:34 +02:00
/*
* Error-reporting support for RemoveRelations
*/
struct dropmsgstrings
{
char kind;
int nonexistent_code;
const char *nonexistent_msg;
const char *skipping_msg;
const char *nota_msg;
const char *drophint_msg;
};
static const struct dropmsgstrings dropmsgstringarray[] = {
{RELKIND_RELATION,
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
ERRCODE_UNDEFINED_TABLE,
gettext_noop("table \"%s\" does not exist"),
gettext_noop("table \"%s\" does not exist, skipping"),
gettext_noop("\"%s\" is not a table"),
gettext_noop("Use DROP TABLE to remove a table.")},
Refactor the handling of the various DropStmt variants so that when multiple objects are specified, we drop them all in a single performMultipleDeletions call. This makes the RESTRICT/CASCADE checks more relaxed: it's not counted as a cascade if one of the later objects has a dependency on an earlier one. NOTICE messages about such cases go away, too. In passing, fix the permissions check for DROP CONVERSION, which for some reason was never made role-aware, and omitted the namespace-owner exemption too. Alex Hunsaker, with further fiddling by me.
2008-06-14 20:04:34 +02:00
{RELKIND_SEQUENCE,
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
ERRCODE_UNDEFINED_TABLE,
gettext_noop("sequence \"%s\" does not exist"),
gettext_noop("sequence \"%s\" does not exist, skipping"),
gettext_noop("\"%s\" is not a sequence"),
gettext_noop("Use DROP SEQUENCE to remove a sequence.")},
Refactor the handling of the various DropStmt variants so that when multiple objects are specified, we drop them all in a single performMultipleDeletions call. This makes the RESTRICT/CASCADE checks more relaxed: it's not counted as a cascade if one of the later objects has a dependency on an earlier one. NOTICE messages about such cases go away, too. In passing, fix the permissions check for DROP CONVERSION, which for some reason was never made role-aware, and omitted the namespace-owner exemption too. Alex Hunsaker, with further fiddling by me.
2008-06-14 20:04:34 +02:00
{RELKIND_VIEW,
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
ERRCODE_UNDEFINED_TABLE,
gettext_noop("view \"%s\" does not exist"),
gettext_noop("view \"%s\" does not exist, skipping"),
gettext_noop("\"%s\" is not a view"),
gettext_noop("Use DROP VIEW to remove a view.")},
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
{RELKIND_MATVIEW,
ERRCODE_UNDEFINED_TABLE,
gettext_noop("materialized view \"%s\" does not exist"),
gettext_noop("materialized view \"%s\" does not exist, skipping"),
gettext_noop("\"%s\" is not a materialized view"),
gettext_noop("Use DROP MATERIALIZED VIEW to remove a materialized view.")},
Refactor the handling of the various DropStmt variants so that when multiple objects are specified, we drop them all in a single performMultipleDeletions call. This makes the RESTRICT/CASCADE checks more relaxed: it's not counted as a cascade if one of the later objects has a dependency on an earlier one. NOTICE messages about such cases go away, too. In passing, fix the permissions check for DROP CONVERSION, which for some reason was never made role-aware, and omitted the namespace-owner exemption too. Alex Hunsaker, with further fiddling by me.
2008-06-14 20:04:34 +02:00
{RELKIND_INDEX,
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
ERRCODE_UNDEFINED_OBJECT,
gettext_noop("index \"%s\" does not exist"),
gettext_noop("index \"%s\" does not exist, skipping"),
gettext_noop("\"%s\" is not an index"),
gettext_noop("Use DROP INDEX to remove an index.")},
Refactor the handling of the various DropStmt variants so that when multiple objects are specified, we drop them all in a single performMultipleDeletions call. This makes the RESTRICT/CASCADE checks more relaxed: it's not counted as a cascade if one of the later objects has a dependency on an earlier one. NOTICE messages about such cases go away, too. In passing, fix the permissions check for DROP CONVERSION, which for some reason was never made role-aware, and omitted the namespace-owner exemption too. Alex Hunsaker, with further fiddling by me.
2008-06-14 20:04:34 +02:00
{RELKIND_COMPOSITE_TYPE,
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
ERRCODE_UNDEFINED_OBJECT,
gettext_noop("type \"%s\" does not exist"),
gettext_noop("type \"%s\" does not exist, skipping"),
gettext_noop("\"%s\" is not a type"),
gettext_noop("Use DROP TYPE to remove a type.")},
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
{RELKIND_FOREIGN_TABLE,
ERRCODE_UNDEFINED_OBJECT,
gettext_noop("foreign table \"%s\" does not exist"),
gettext_noop("foreign table \"%s\" does not exist, skipping"),
gettext_noop("\"%s\" is not a foreign table"),
gettext_noop("Use DROP FOREIGN TABLE to remove a foreign table.")},
Refactor the handling of the various DropStmt variants so that when multiple objects are specified, we drop them all in a single performMultipleDeletions call. This makes the RESTRICT/CASCADE checks more relaxed: it's not counted as a cascade if one of the later objects has a dependency on an earlier one. NOTICE messages about such cases go away, too. In passing, fix the permissions check for DROP CONVERSION, which for some reason was never made role-aware, and omitted the namespace-owner exemption too. Alex Hunsaker, with further fiddling by me.
2008-06-14 20:04:34 +02:00
{'\0', 0, NULL, NULL, NULL, NULL}
};
Improve table locking behavior in the face of current DDL. In the previous coding, callers were faced with an awkward choice: look up the name, do permissions checks, and then lock the table; or look up the name, lock the table, and then do permissions checks. The first choice was wrong because the results of the name lookup and permissions checks might be out-of-date by the time the table lock was acquired, while the second allowed a user with no privileges to interfere with access to a table by users who do have privileges (e.g. if a malicious backend queues up for an AccessExclusiveLock on a table on which AccessShareLock is already held, further attempts to access the table will be blocked until the AccessExclusiveLock is obtained and the malicious backend's transaction rolls back). To fix, allow callers of RangeVarGetRelid() to pass a callback which gets executed after performing the name lookup but before acquiring the relation lock. If the name lookup is retried (because invalidation messages are received), the callback will be re-executed as well, so we get the best of both worlds. RangeVarGetRelid() is renamed to RangeVarGetRelidExtended(); callers not wishing to supply a callback can continue to invoke it as RangeVarGetRelid(), which is now a macro. Since the only one caller that uses nowait = true now passes a callback anyway, the RangeVarGetRelid() macro defaults nowait as well. The callback can also be used for supplemental locking - for example, REINDEX INDEX needs to acquire the table lock before the index lock to reduce deadlock possibilities. There's a lot more work to be done here to fix all the cases where this can be a problem, but this commit provides the general infrastructure and fixes the following specific cases: REINDEX INDEX, REINDEX TABLE, LOCK TABLE, and and DROP TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE. Per discussion with Noah Misch and Alvaro Herrera.
2011-11-30 16:12:27 +01:00
struct DropRelationCallbackState
{
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
char relkind;
Oid heapOid;
bool concurrent;
Improve table locking behavior in the face of current DDL. In the previous coding, callers were faced with an awkward choice: look up the name, do permissions checks, and then lock the table; or look up the name, lock the table, and then do permissions checks. The first choice was wrong because the results of the name lookup and permissions checks might be out-of-date by the time the table lock was acquired, while the second allowed a user with no privileges to interfere with access to a table by users who do have privileges (e.g. if a malicious backend queues up for an AccessExclusiveLock on a table on which AccessShareLock is already held, further attempts to access the table will be blocked until the AccessExclusiveLock is obtained and the malicious backend's transaction rolls back). To fix, allow callers of RangeVarGetRelid() to pass a callback which gets executed after performing the name lookup but before acquiring the relation lock. If the name lookup is retried (because invalidation messages are received), the callback will be re-executed as well, so we get the best of both worlds. RangeVarGetRelid() is renamed to RangeVarGetRelidExtended(); callers not wishing to supply a callback can continue to invoke it as RangeVarGetRelid(), which is now a macro. Since the only one caller that uses nowait = true now passes a callback anyway, the RangeVarGetRelid() macro defaults nowait as well. The callback can also be used for supplemental locking - for example, REINDEX INDEX needs to acquire the table lock before the index lock to reduce deadlock possibilities. There's a lot more work to be done here to fix all the cases where this can be a problem, but this commit provides the general infrastructure and fixes the following specific cases: REINDEX INDEX, REINDEX TABLE, LOCK TABLE, and and DROP TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE. Per discussion with Noah Misch and Alvaro Herrera.
2011-11-30 16:12:27 +01:00
};
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
/* Alter table target-type flags for ATSimplePermissions */
#define ATT_TABLE 0x0001
#define ATT_VIEW 0x0002
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
#define ATT_MATVIEW 0x0004
#define ATT_INDEX 0x0008
#define ATT_COMPOSITE_TYPE 0x0010
#define ATT_FOREIGN_TABLE 0x0020
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Dept. of second thoughts: rejigger the TRUNCATE ... CASCADE patch so that 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.
2006-03-03 19:25:14 +01:00
static void truncate_check_rel(Relation rel);
Generalize concept of temporary relations to "relation persistence". This commit replaces pg_class.relistemp with pg_class.relpersistence; and also modifies the RangeVar node type to carry relpersistence rather than istemp. It also removes removes rd_istemp from RelationData and instead performs the correct computation based on relpersistence. For clarity, we add three new macros: RelationNeedsWAL(), RelationUsesLocalBuffers(), and RelationUsesTempNamespace(), so that we can clarify the purpose of each check that previous depended on rd_istemp. This is intended as infrastructure for the upcoming unlogged tables patch, as well as for future possible work on global temporary tables.
2010-12-13 18:34:26 +01:00
static List *MergeAttributes(List *schema, List *supers, char relpersistence,
Upgrade ALTER TABLE DROP COLUMN so that it can drop an OID column, and remove separate implementation of ALTER TABLE SET WITHOUT OIDS in favor of doing a regular DROP. Also, cause CREATE TABLE to account completely correctly for the inheritance status of the OID column. This fixes problems with dropping OID columns that have dependencies, as noted by Christopher Kings-Lynne, as well as making sure that you can't drop an OID column that was inherited from a parent.
2004-03-23 20:35:17 +01:00
List **supOids, List **supconstr, int *supOidCount);
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
static bool MergeCheckConstraint(List *constraints, char *name, Node *expr);
static void MergeAttributesIntoExisting(Relation child_rel, Relation parent_rel);
static void MergeConstraintsIntoExisting(Relation child_rel, Relation parent_rel);
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
static void StoreCatalogInheritance(Oid relationId, List *supers);
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
static void StoreCatalogInheritance1(Oid relationId, Oid parentOid,
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
int16 seqNumber, Relation inhRelation);
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
static int findAttrByName(const char *attributeName, List *schema);
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
static void AlterIndexNamespaces(Relation classRel, Relation rel,
pgindent run for release 9.3 This is the first run of the Perl-based pgindent script. Also update pgindent instructions.
2013-05-29 22:58:43 +02:00
Oid oldNspOid, Oid newNspOid, ObjectAddresses *objsMoved);
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
static void AlterSeqNamespaces(Relation classRel, Relation rel,
Fix ALTER EXTENSION / SET SCHEMA In its original conception, it was leaving some objects into the old schema, but without their proper pg_depend entries; this meant that the old schema could be dropped, causing future pg_dump calls to fail on the affected database. This was originally reported by Jeff Frost as #6704; there have been other complaints elsewhere that can probably be traced to this bug. To fix, be more consistent about altering a table's subsidiary objects along the table itself; this requires some restructuring in how tables are relocated when altering an extension -- hence the new AlterTableNamespaceInternal routine which encapsulates it for both the ALTER TABLE and the ALTER EXTENSION cases. There was another bug lurking here, which was unmasked after fixing the previous one: certain objects would be reached twice via the dependency graph, and the second attempt to move them would cause the entire operation to fail. Per discussion, it seems the best fix for this is to do more careful tracking of objects already moved: we now maintain a list of moved objects, to avoid attempting to do it twice for the same object. Authors: Alvaro Herrera, Dimitri Fontaine Reviewed by Tom Lane
2012-10-31 14:52:55 +01:00
Oid oldNspOid, Oid newNspOid, ObjectAddresses *objsMoved,
LOCKMODE lockmode);
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
static void ATExecValidateConstraint(Relation rel, char *constrName,
bool recurse, bool recursing, LOCKMODE lockmode);
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
static int transformColumnNameList(Oid relId, List *colList,
pgindent run.
2003-08-04 02:43:34 +02:00
int16 *attnums, Oid *atttypids);
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
static int transformFkeyGetPrimaryKey(Relation pkrel, Oid *indexOid,
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
List **attnamelist,
int16 *attnums, Oid *atttypids,
Oid *opclasses);
pgindent run.
2003-08-04 02:43:34 +02:00
static Oid transformFkeyCheckAttrs(Relation pkrel,
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
int numattrs, int16 *attnums,
Oid *opclasses);
Support column-level privileges, as required by SQL standard. Stephen Frost, with help from KaiGai Kohei and others
2009-01-22 21:16:10 +01:00
static void checkFkeyPermissions(Relation rel, int16 *attnums, int natts);
ALTER TABLE: skip FK validation when it's safe to do so We already skip rewriting the table in these cases, but we still force a whole table scan to validate the data. This can be skipped, and thus we can make the whole ALTER TABLE operation just do some catalog touches instead of scanning the table, when these two conditions hold: (a) Old and new pg_constraint.conpfeqop match exactly. This is actually stronger than needed; we could loosen things by way of operator families, but it'd require a lot more effort. (b) The functions, if any, implementing a cast from the foreign type to the primary opcintype are the same. For this purpose, we can consider a binary coercion equivalent to an exact type match. When the opcintype is polymorphic, require that the old and new foreign types match exactly. (Since ri_triggers.c does use the executor, the stronger check for polymorphic types is no mere future-proofing. However, no core type exercises its necessity.) Author: Noah Misch Committer's note: catalog version bumped due to change of the Constraint node. I can't actually find any way to have such a node in a stored rule, but given that we have "out" support for them, better be safe.
2012-02-27 22:28:00 +01:00
static CoercionPathType findFkeyCast(Oid targetTypeId, Oid sourceTypeId,
Oid *funcid);
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
static void validateCheckConstraint(Relation rel, HeapTuple constrtup);
Extend ALTER TABLE to allow Foreign Keys to be added without initial validation. 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
2011-02-08 13:23:20 +01:00
static void validateForeignKeyConstraint(char *conname,
Add system catalog columns pg_constraint.conindid and pg_trigger.tgconstrindid. conindid is the index supporting a constraint. We can use this not only for unique/primary-key constraints, but also foreign-key constraints, which depend on the unique index that constrains the referenced columns. tgconstrindid is just copied from the constraint's conindid field, or is zero for triggers not associated with constraints. This is mainly intended as infrastructure for upcoming patches, but it has some virtue in itself, since it exposes a relationship that you formerly had to grovel in pg_depend to determine. I simplified one information_schema view accordingly. (There is a pg_dump query that could also use conindid, but I left it alone because it wasn't clear it'd get any faster.)
2009-07-28 04:56:31 +02:00
Relation rel, Relation pkrel,
Oid pkindOid, Oid constraintOid);
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
static void createForeignKeyTriggers(Relation rel, Constraint *fkconstraint,
Add system catalog columns pg_constraint.conindid and pg_trigger.tgconstrindid. conindid is the index supporting a constraint. We can use this not only for unique/primary-key constraints, but also foreign-key constraints, which depend on the unique index that constrains the referenced columns. tgconstrindid is just copied from the constraint's conindid field, or is zero for triggers not associated with constraints. This is mainly intended as infrastructure for upcoming patches, but it has some virtue in itself, since it exposes a relationship that you formerly had to grovel in pg_depend to determine. I simplified one information_schema view accordingly. (There is a pg_dump query that could also use conindid, but I left it alone because it wasn't clear it'd get any faster.)
2009-07-28 04:56:31 +02:00
Oid constraintOid, Oid indexOid);
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
static void ATController(Relation rel, List *cmds, bool recurse, LOCKMODE lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static void ATPrepCmd(List **wqueue, Relation rel, AlterTableCmd *cmd,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
bool recurse, bool recursing, LOCKMODE lockmode);
static void ATRewriteCatalogs(List **wqueue, LOCKMODE lockmode);
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
static void ATExecCmd(List **wqueue, AlteredTableInfo *tab, Relation rel,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
AlterTableCmd *cmd, LOCKMODE lockmode);
static void ATRewriteTables(List **wqueue, LOCKMODE lockmode);
static void ATRewriteTable(AlteredTableInfo *tab, Oid OIDNewHeap, LOCKMODE lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static AlteredTableInfo *ATGetQueueEntry(List **wqueue, Relation rel);
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
static void ATSimplePermissions(Relation rel, int allowed_targets);
static void ATWrongRelkindError(Relation rel, int allowed_targets);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static void ATSimpleRecursion(List **wqueue, Relation rel,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
AlterTableCmd *cmd, bool recurse, LOCKMODE lockmode);
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
static void ATTypedTableRecursion(List **wqueue, Relation rel, AlterTableCmd *cmd,
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
LOCKMODE lockmode);
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
static List *find_typed_table_dependencies(Oid typeOid, const char *typeName,
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
DropBehavior behavior);
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
static void ATPrepAddColumn(List **wqueue, Relation rel, bool recurse, bool recursing,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
AlterTableCmd *cmd, LOCKMODE lockmode);
Rearrange "add column" logic to merge columns at exec time. 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.
2011-04-04 03:52:47 +02:00
static void ATExecAddColumn(List **wqueue, AlteredTableInfo *tab, Relation rel,
ColumnDef *colDef, bool isOid,
bool recurse, bool recursing, LOCKMODE lockmode);
Be more clear when a new column name collides with a system column name. We now use the same error message for ALTER TABLE .. ADD COLUMN or ALTER TABLE .. RENAME COLUMN that we do for CREATE TABLE. The old message was accurate, but might be confusing to users not aware of our system columns. Vik Reykja, with some changes by me, and further proofreading by Tom Lane
2012-01-26 18:44:30 +01:00
static void check_for_column_name_collision(Relation rel, const char *colname);
Make a code-cleanup pass over the collations patch. 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().
2011-04-22 23:43:18 +02:00
static void add_column_datatype_dependency(Oid relid, int32 attnum, Oid typid);
static void add_column_collation_dependency(Oid relid, int32 attnum, Oid collid);
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
static void ATPrepAddOids(List **wqueue, Relation rel, bool recurse,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
AlterTableCmd *cmd, LOCKMODE lockmode);
static void ATExecDropNotNull(Relation rel, const char *colName, LOCKMODE lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static void ATExecSetNotNull(AlteredTableInfo *tab, Relation rel,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
const char *colName, LOCKMODE lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static void ATExecColumnDefault(Relation rel, const char *colName,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
Node *newDefault, LOCKMODE lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static void ATPrepSetStatistics(Relation rel, const char *colName,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
Node *newValue, LOCKMODE lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static void ATExecSetStatistics(Relation rel, const char *colName,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
Node *newValue, LOCKMODE lockmode);
Replace ALTER TABLE ... SET STATISTICS DISTINCT with a more general mechanism. Attributes can now have options, just as relations and tablespaces do, and the reloptions code is used to parse, validate, and store them. For simplicity and because these options are not performance critical, we store them in a separate cache rather than the main relcache. Thanks to Alex Hunsaker for the review.
2010-01-22 17:40:19 +01:00
static void ATExecSetOptions(Relation rel, const char *colName,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
Node *options, bool isReset, LOCKMODE lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static void ATExecSetStorage(Relation rel, const char *colName,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
Node *newValue, LOCKMODE lockmode);
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
static void ATPrepDropColumn(List **wqueue, Relation rel, bool recurse, bool recursing,
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
AlterTableCmd *cmd, LOCKMODE lockmode);
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
static void ATExecDropColumn(List **wqueue, Relation rel, const char *colName,
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
DropBehavior behavior,
DROP IF EXISTS for columns and constraints. Andres Freund.
2009-07-20 04:42:28 +02:00
bool recurse, bool recursing,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
bool missing_ok, LOCKMODE lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static void ATExecAddIndex(AlteredTableInfo *tab, Relation rel,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
IndexStmt *stmt, bool is_rebuild, LOCKMODE lockmode);
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
static void ATExecAddConstraint(List **wqueue,
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
AlteredTableInfo *tab, Relation rel,
Fix handling of inherited check constraints in ALTER COLUMN TYPE. This case got broken in 8.4 by the addition of an error check that complains if ALTER TABLE ONLY is used on a table that has children. We do use ONLY for this situation, but it's okay because the necessary recursion occurs at a higher level. So we need to have a separate flag to suppress recursion without making the error check. Reported and patched by Pavan Deolasee, with some editorial adjustments by me. Back-patch to 8.4, since this is a regression of functionality that worked in earlier branches.
2012-11-05 19:36:16 +01:00
Constraint *newConstraint, bool recurse, bool is_readd,
LOCKMODE lockmode);
Implement ALTER TABLE ADD UNIQUE/PRIMARY KEY USING INDEX. This feature allows a unique or pkey constraint to be created using an already-existing unique index. While the constraint isn't very functionally different from the bare index, it's nice to be able to do that for documentation purposes. The main advantage over just issuing a plain ALTER TABLE ADD UNIQUE/PRIMARY KEY is that the index can be created with CREATE INDEX CONCURRENTLY, so that there is not a long interval where the table is locked against updates. On the way, refactor some of the code in DefineIndex() and index_create() so that we don't have to pass through those functions in order to create the index constraint's catalog entries. Also, in parse_utilcmd.c, pass around the ParseState pointer in struct CreateStmtContext to save on notation, and add error location pointers to some error reports that didn't have one before. Gurjeet Singh, reviewed by Steve Singer and Tom Lane
2011-01-25 21:42:03 +01:00
static void ATExecAddIndexConstraint(AlteredTableInfo *tab, Relation rel,
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
IndexStmt *stmt, LOCKMODE lockmode);
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
static void ATAddCheckConstraint(List **wqueue,
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
AlteredTableInfo *tab, Relation rel,
Constraint *constr,
Fix handling of inherited check constraints in ALTER COLUMN TYPE. This case got broken in 8.4 by the addition of an error check that complains if ALTER TABLE ONLY is used on a table that has children. We do use ONLY for this situation, but it's okay because the necessary recursion occurs at a higher level. So we need to have a separate flag to suppress recursion without making the error check. Reported and patched by Pavan Deolasee, with some editorial adjustments by me. Back-patch to 8.4, since this is a regression of functionality that worked in earlier branches.
2012-11-05 19:36:16 +01:00
bool recurse, bool recursing, bool is_readd,
LOCKMODE lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static void ATAddForeignKeyConstraint(AlteredTableInfo *tab, Relation rel,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
Constraint *fkconstraint, LOCKMODE lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static void ATExecDropConstraint(Relation rel, const char *constrName,
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
DropBehavior behavior,
bool recurse, bool recursing,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
bool missing_ok, LOCKMODE lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static void ATPrepAlterColumnType(List **wqueue,
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
AlteredTableInfo *tab, Relation rel,
bool recurse, bool recursing,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
AlterTableCmd *cmd, LOCKMODE lockmode);
Teach ALTER TABLE .. SET DATA TYPE to avoid some table rewrites. 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
2011-02-12 14:27:55 +01:00
static bool ATColumnChangeRequiresRewrite(Node *expr, AttrNumber varattno);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static void ATExecAlterColumnType(AlteredTableInfo *tab, Relation rel,
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
AlterTableCmd *cmd, LOCKMODE lockmode);
Allow per-column foreign data wrapper options. Shigeru Hanada, with fairly minor editing by me.
2011-08-05 19:24:03 +02:00
static void ATExecAlterColumnGenericOptions(Relation rel, const char *colName,
List *options, LOCKMODE lockmode);
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
static void ATPostAlterTypeCleanup(List **wqueue, AlteredTableInfo *tab, LOCKMODE lockmode);
Avoid index rebuild for no-rewrite ALTER TABLE .. ALTER TYPE. Noah Misch. Review and minor cosmetic changes by me.
2011-07-18 17:02:48 +02:00
static void ATPostAlterTypeParse(Oid oldId, char *cmd,
List **wqueue, LOCKMODE lockmode, bool rewrite);
static void TryReuseIndex(Oid oldId, IndexStmt *stmt);
ALTER TABLE: skip FK validation when it's safe to do so We already skip rewriting the table in these cases, but we still force a whole table scan to validate the data. This can be skipped, and thus we can make the whole ALTER TABLE operation just do some catalog touches instead of scanning the table, when these two conditions hold: (a) Old and new pg_constraint.conpfeqop match exactly. This is actually stronger than needed; we could loosen things by way of operator families, but it'd require a lot more effort. (b) The functions, if any, implementing a cast from the foreign type to the primary opcintype are the same. For this purpose, we can consider a binary coercion equivalent to an exact type match. When the opcintype is polymorphic, require that the old and new foreign types match exactly. (Since ri_triggers.c does use the executor, the stronger check for polymorphic types is no mere future-proofing. However, no core type exercises its necessity.) Author: Noah Misch Committer's note: catalog version bumped due to change of the Constraint node. I can't actually find any way to have such a node in a stored rule, but given that we have "out" support for them, better be safe.
2012-02-27 22:28:00 +01:00
static void TryReuseForeignKey(Oid oldId, Constraint *con);
Update per-column ACLs, not only per-table ACL, when changing table owner. We forgot to modify column ACLs, so privileges were still shown as having been granted by the old owner. This meant that neither the new owner nor a superuser could revoke the now-untraceable-to-table-owner permissions. Per bug #6350 from Marc Balmer. This has been wrong since column ACLs were added, so back-patch to 8.4.
2011-12-22 00:23:11 +01:00
static void change_owner_fix_column_acls(Oid relationOid,
Oid oldOwnerId, Oid newOwnerId);
Fix ALTER TABLE OWNER to adjust the ownership of dependent sequences, not only indexes. Alvaro Herrera, with some kibitzing by Tom Lane.
2004-09-24 01:20:24 +02:00
static void change_owner_recurse_to_sequences(Oid relationOid,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
Oid newOwnerId, LOCKMODE lockmode);
static void ATExecClusterOn(Relation rel, const char *indexName, LOCKMODE lockmode);
static void ATExecDropCluster(Relation rel, LOCKMODE lockmode);
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
static void ATPrepSetTableSpace(AlteredTableInfo *tab, Relation rel,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
char *tablespacename, LOCKMODE lockmode);
static void ATExecSetTableSpace(Oid tableOid, Oid newTableSpace, LOCKMODE lockmode);
Add a security_barrier option for views. When a view is marked as a security barrier, it will not be pulled up into the containing query, and no quals will be pushed down into it, so that no function or operator chosen by the user can be applied to rows not exposed by the view. Views not configured with this option cannot provide robust row-level security, but will perform far better. Patch by KaiGai Kohei; original problem report by Heikki Linnakangas (in October 2009!). Review (in earlier versions) by Noah Misch and others. Design advice by Tom Lane and myself. Further review and cleanup by me.
2011-12-22 22:15:57 +01:00
static void ATExecSetRelOptions(Relation rel, List *defList,
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
AlterTableType operation,
LOCKMODE lockmode);
Add ALTER TABLE ENABLE/DISABLE TRIGGER commands. Change pg_dump to use these instead of its previous hack of changing pg_class.reltriggers. Documentation is lacking, will add that later. Patch by Satoshi Nagayasu, review and some extra work by Tom Lane.
2005-08-24 00:40:47 +02:00
static void ATExecEnableDisableTrigger(Relation rel, char *trigname,
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
char fires_when, bool skip_system, LOCKMODE lockmode);
Changes pg_trigger and extend pg_rewrite in order to allow triggers and 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
2007-03-20 00:38:32 +01:00
static void ATExecEnableDisableRule(Relation rel, char *rulename,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
char fires_when, LOCKMODE lockmode);
Add more checks against altering typed tables - Prohibit altering column type - Prohibit changing inheritance - Move checks from Exec to Prep phases in ALTER TABLE code backpatched to 9.0
2010-07-23 22:04:18 +02:00
static void ATPrepAddInherit(Relation child_rel);
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
static void ATExecAddInherit(Relation child_rel, RangeVar *parent, LOCKMODE lockmode);
static void ATExecDropInherit(Relation rel, RangeVar *parent, LOCKMODE lockmode);
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
static void drop_parent_dependency(Oid relid, Oid refclassid, Oid refobjid);
static void ATExecAddOf(Relation rel, const TypeName *ofTypename, LOCKMODE lockmode);
static void ATExecDropOf(Relation rel, LOCKMODE lockmode);
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
static void ATExecGenericOptions(Relation rel, List *options);
Introduce the concept of relation forks. An smgr relation can now consist of multiple forks, and each fork can be created and grown separately. The bulk of this patch is about changing the smgr API to include an extra ForkNumber argument in every smgr function. Also, smgrscheduleunlink and smgrdounlink no longer implicitly call smgrclose, because other forks might still exist after unlinking one. The callers of those functions have been modified to call smgrclose instead. This patch in itself doesn't have any user-visible effect, but provides the infrastructure needed for upcoming patches. The additional forks envisioned are a rewritten FSM implementation that doesn't rely on a fixed-size shared memory block, and a visibility map to allow skipping portions of a table in VACUUM that have no dead tuples.
2008-08-11 13:05:11 +02:00
static void copy_relation_data(SMgrRelation rel, SMgrRelation dst,
Generalize concept of temporary relations to "relation persistence". This commit replaces pg_class.relistemp with pg_class.relpersistence; and also modifies the RangeVar node type to carry relpersistence rather than istemp. It also removes removes rd_istemp from RelationData and instead performs the correct computation based on relpersistence. For clarity, we add three new macros: RelationNeedsWAL(), RelationUsesLocalBuffers(), and RelationUsesTempNamespace(), so that we can clarify the purpose of each check that previous depended on rd_istemp. This is intended as infrastructure for the upcoming unlogged tables patch, as well as for future possible work on global temporary tables.
2010-12-13 18:34:26 +01:00
ForkNumber forkNum, char relpersistence);
Code review for LIKE INCLUDING patch --- clean up some cosmetic and not so cosmetic stuff.
2009-10-13 02:53:08 +02:00
static const char *storage_name(char c);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Improve table locking behavior in the face of current DDL. In the previous coding, callers were faced with an awkward choice: look up the name, do permissions checks, and then lock the table; or look up the name, lock the table, and then do permissions checks. The first choice was wrong because the results of the name lookup and permissions checks might be out-of-date by the time the table lock was acquired, while the second allowed a user with no privileges to interfere with access to a table by users who do have privileges (e.g. if a malicious backend queues up for an AccessExclusiveLock on a table on which AccessShareLock is already held, further attempts to access the table will be blocked until the AccessExclusiveLock is obtained and the malicious backend's transaction rolls back). To fix, allow callers of RangeVarGetRelid() to pass a callback which gets executed after performing the name lookup but before acquiring the relation lock. If the name lookup is retried (because invalidation messages are received), the callback will be re-executed as well, so we get the best of both worlds. RangeVarGetRelid() is renamed to RangeVarGetRelidExtended(); callers not wishing to supply a callback can continue to invoke it as RangeVarGetRelid(), which is now a macro. Since the only one caller that uses nowait = true now passes a callback anyway, the RangeVarGetRelid() macro defaults nowait as well. The callback can also be used for supplemental locking - for example, REINDEX INDEX needs to acquire the table lock before the index lock to reduce deadlock possibilities. There's a lot more work to be done here to fix all the cases where this can be a problem, but this commit provides the general infrastructure and fixes the following specific cases: REINDEX INDEX, REINDEX TABLE, LOCK TABLE, and and DROP TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE. Per discussion with Noah Misch and Alvaro Herrera.
2011-11-30 16:12:27 +01:00
static void RangeVarCallbackForDropRelation(const RangeVar *rel, Oid relOid,
Oid oldRelOid, void *arg);
Improve behavior of concurrent ALTER TABLE, and do some refactoring. ALTER TABLE (and ALTER VIEW, ALTER SEQUENCE, etc.) now use a RangeVarGetRelid callback to check permissions before acquiring a table lock. We also now use the same callback for all forms of ALTER TABLE, rather than having separate, almost-identical callbacks for ALTER TABLE .. SET SCHEMA and ALTER TABLE .. RENAME, and no callback at all for everything else. I went ahead and changed the code so that no form of ALTER TABLE works on foreign tables; you must use ALTER FOREIGN TABLE instead. In 9.1, it was possible to use ALTER TABLE .. SET SCHEMA or ALTER TABLE .. RENAME on a foreign table, but not any other form of ALTER TABLE, which did not seem terribly useful or consistent. Patch by me; review by Noah Misch.
2012-01-07 04:42:26 +01:00
static void RangeVarCallbackForAlterRelation(const RangeVar *rv, Oid relid,
Oid oldrelid, void *arg);
Improve table locking behavior in the face of current DDL. In the previous coding, callers were faced with an awkward choice: look up the name, do permissions checks, and then lock the table; or look up the name, lock the table, and then do permissions checks. The first choice was wrong because the results of the name lookup and permissions checks might be out-of-date by the time the table lock was acquired, while the second allowed a user with no privileges to interfere with access to a table by users who do have privileges (e.g. if a malicious backend queues up for an AccessExclusiveLock on a table on which AccessShareLock is already held, further attempts to access the table will be blocked until the AccessExclusiveLock is obtained and the malicious backend's transaction rolls back). To fix, allow callers of RangeVarGetRelid() to pass a callback which gets executed after performing the name lookup but before acquiring the relation lock. If the name lookup is retried (because invalidation messages are received), the callback will be re-executed as well, so we get the best of both worlds. RangeVarGetRelid() is renamed to RangeVarGetRelidExtended(); callers not wishing to supply a callback can continue to invoke it as RangeVarGetRelid(), which is now a macro. Since the only one caller that uses nowait = true now passes a callback anyway, the RangeVarGetRelid() macro defaults nowait as well. The callback can also be used for supplemental locking - for example, REINDEX INDEX needs to acquire the table lock before the index lock to reduce deadlock possibilities. There's a lot more work to be done here to fix all the cases where this can be a problem, but this commit provides the general infrastructure and fixes the following specific cases: REINDEX INDEX, REINDEX TABLE, LOCK TABLE, and and DROP TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE. Per discussion with Noah Misch and Alvaro Herrera.
2011-11-30 16:12:27 +01:00
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/* ----------------------------------------------------------------
* DefineRelation
* Creates a new relation.
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*
Fix failure of "ALTER TABLE t ADD COLUMN c serial" when done by non-owner. The implicitly created sequence was created as owned by the current user, who could be different from the table owner, eg if current user is a superuser or some member of the table's owning role. This caused sanity checks in the SEQUENCE OWNED BY code to spit up. Although possibly we don't need those sanity checks, the safest fix seems to be to make sure the implicit sequence is assigned the same owner role as the table has. (We still do all permissions checks as the current user, however.) Per report from Josh Berkus. Back-patch to 9.0. The bug goes back to the invention of SEQUENCE OWNED BY in 8.2, but the fix requires an API change for DefineRelation(), which seems to have potential for breaking third-party code if done in a minor release. Given the lack of prior complaints, it's probably not worth fixing in the stable branches.
2010-08-18 20:35:21 +02:00
* stmt carries parsetree information from an ordinary CREATE TABLE statement.
* The other arguments are used to extend the behavior for other cases:
* relkind: relkind to assign to the new relation
* ownerId: if not InvalidOid, use this as the new relation's owner.
*
* Note that permissions checks are done against current user regardless of
* ownerId. A nonzero ownerId is used when someone is creating a relation
* "on behalf of" someone else, so we still want to see that the current user
* has permissions to do it.
*
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
* If successful, returns the OID of the new relation.
* ----------------------------------------------------------------
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
Oid
Fix failure of "ALTER TABLE t ADD COLUMN c serial" when done by non-owner. The implicitly created sequence was created as owned by the current user, who could be different from the table owner, eg if current user is a superuser or some member of the table's owning role. This caused sanity checks in the SEQUENCE OWNED BY code to spit up. Although possibly we don't need those sanity checks, the safest fix seems to be to make sure the implicit sequence is assigned the same owner role as the table has. (We still do all permissions checks as the current user, however.) Per report from Josh Berkus. Back-patch to 9.0. The bug goes back to the invention of SEQUENCE OWNED BY in 8.2, but the fix requires an API change for DefineRelation(), which seems to have potential for breaking third-party code if done in a minor release. Given the lack of prior complaints, it's probably not worth fixing in the stable branches.
2010-08-18 20:35:21 +02:00
DefineRelation(CreateStmt *stmt, char relkind, Oid ownerId)
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
char relname[NAMEDATALEN];
Oid namespaceId;
List *schema = stmt->tableElts;
Oid relationId;
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
Oid tablespaceId;
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
Relation rel;
TupleDesc descriptor;
List *inheritOids;
List *old_constraints;
Upgrade ALTER TABLE DROP COLUMN so that it can drop an OID column, and remove separate implementation of ALTER TABLE SET WITHOUT OIDS in favor of doing a regular DROP. Also, cause CREATE TABLE to account completely correctly for the inheritance status of the OID column. This fixes problems with dropping OID columns that have dependencies, as noted by Christopher Kings-Lynne, as well as making sure that you can't drop an OID column that was inherited from a parent.
2004-03-23 20:35:17 +01:00
bool localHasOids;
int parentOidCount;
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
List *rawDefaults;
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
List *cookedDefaults;
Code review for FILLFACTOR patch. Change WITH grammar as per earlier 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.
2006-07-04 00:45:41 +02:00
Datum reloptions;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *listptr;
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
AttrNumber attnum;
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
static char *validnsps[] = HEAP_RELOPT_NAMESPACES;
Type table feature This adds the CREATE TABLE name OF type command, per SQL standard.
2010-01-29 00:21:13 +01:00
Oid ofTypeId;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Change the aclchk.c routines to uniformly use OIDs to identify the objects to be privilege-checked. Some change in their APIs would be necessary no matter what in the schema environment, and simply getting rid of the name-based interface entirely seems like the best way.
2002-03-22 00:27:25 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Truncate relname to appropriate length (probably a waste of time, as
* parser should have done this already).
Change the aclchk.c routines to uniformly use OIDs to identify the objects to be privilege-checked. Some change in their APIs would be necessary no matter what in the schema environment, and simply getting rid of the name-based interface entirely seems like the best way.
2002-03-22 00:27:25 +01:00
*/
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
StrNCpy(relname, stmt->relation->relname, NAMEDATALEN);
Change the aclchk.c routines to uniformly use OIDs to identify the objects to be privilege-checked. Some change in their APIs would be necessary no matter what in the schema environment, and simply getting rid of the name-based interface entirely seems like the best way.
2002-03-22 00:27:25 +01:00
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
/*
* Check consistency of arguments
*/
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
if (stmt->oncommit != ONCOMMIT_NOOP
Generalize concept of temporary relations to "relation persistence". This commit replaces pg_class.relistemp with pg_class.relpersistence; and also modifies the RangeVar node type to carry relpersistence rather than istemp. It also removes removes rd_istemp from RelationData and instead performs the correct computation based on relpersistence. For clarity, we add three new macros: RelationNeedsWAL(), RelationUsesLocalBuffers(), and RelationUsesTempNamespace(), so that we can clarify the purpose of each check that previous depended on rd_istemp. This is intended as infrastructure for the upcoming unlogged tables patch, as well as for future possible work on global temporary tables.
2010-12-13 18:34:26 +01:00
&& stmt->relation->relpersistence != RELPERSISTENCE_TEMP)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("ON COMMIT can only be used on temporary tables")));
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
if (stmt->constraints != NIL && relkind == RELKIND_FOREIGN_TABLE)
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
Allow default expressions to be attached to columns of foreign tables. There's still some discussion about exactly how postgres_fdw ought to handle this case, but there seems no debate that we want to allow defaults to be used for inserts into foreign tables. So remove the core-code restrictions that prevented it. While at it, get rid of the special grammar productions for CREATE FOREIGN TABLE, and instead add explicit FEATURE_NOT_SUPPORTED error checks for the disallowed cases. This makes the grammar a shade smaller, and more importantly results in much more intelligible error messages for unsupported cases. It's also one less thing to fix if we ever start supporting constraints on foreign tables.
2013-03-12 22:37:07 +01:00
errmsg("constraints are not supported on foreign tables")));
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
Fix bugs in relpersistence handling during table creation. 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.
2011-07-03 23:34:47 +02:00
/*
* Look up the namespace in which we are supposed to create the relation,
Prevent adding relations to a concurrently dropped schema. In the previous coding, it was possible for a relation to be created via CREATE TABLE, CREATE VIEW, CREATE SEQUENCE, CREATE FOREIGN TABLE, etc. in a schema while that schema was meanwhile being concurrently dropped. This led to a pg_class entry with an invalid relnamespace value. The same problem could occur if a relation was moved using ALTER .. SET SCHEMA while the target schema was being concurrently dropped. This patch prevents both of those scenarios by locking the schema to which the relation is being added using AccessShareLock, which conflicts with the AccessExclusiveLock taken by DROP. As a desirable side effect, this also prevents the use of CREATE OR REPLACE VIEW to queue for an AccessExclusiveLock on a relation on which you have no rights: that will now fail immediately with a permissions error, before trying to obtain a lock. We need similar protection for all other object types, but as everything other than relations uses a slightly different set of code paths, I'm leaving that for a separate commit. Original complaint (as far as I could find) about CREATE by Nikhil Sontakke; risk for ALTER .. SET SCHEMA pointed out by Tom Lane; further details by Dan Farina; patch by me; review by Hitoshi Harada.
2012-01-16 15:34:21 +01:00
* check we have permission to create there, lock it against concurrent
* drop, and mark stmt->relation as RELPERSISTENCE_TEMP if a temporary
* namespace is selected.
Fix bugs in relpersistence handling during table creation. 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.
2011-07-03 23:34:47 +02:00
*/
Prevent adding relations to a concurrently dropped schema. In the previous coding, it was possible for a relation to be created via CREATE TABLE, CREATE VIEW, CREATE SEQUENCE, CREATE FOREIGN TABLE, etc. in a schema while that schema was meanwhile being concurrently dropped. This led to a pg_class entry with an invalid relnamespace value. The same problem could occur if a relation was moved using ALTER .. SET SCHEMA while the target schema was being concurrently dropped. This patch prevents both of those scenarios by locking the schema to which the relation is being added using AccessShareLock, which conflicts with the AccessExclusiveLock taken by DROP. As a desirable side effect, this also prevents the use of CREATE OR REPLACE VIEW to queue for an AccessExclusiveLock on a relation on which you have no rights: that will now fail immediately with a permissions error, before trying to obtain a lock. We need similar protection for all other object types, but as everything other than relations uses a slightly different set of code paths, I'm leaving that for a separate commit. Original complaint (as far as I could find) about CREATE by Nikhil Sontakke; risk for ALTER .. SET SCHEMA pointed out by Tom Lane; further details by Dan Farina; patch by me; review by Hitoshi Harada.
2012-01-16 15:34:21 +01:00
namespaceId =
RangeVarGetAndCheckCreationNamespace(stmt->relation, NoLock, NULL);
Fix bugs in relpersistence handling during table creation. 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.
2011-07-03 23:34:47 +02:00
Prevent indirect security attacks via changing session-local state within an allegedly immutable index function. It was previously recognized that we had to prevent such a function from executing SET/RESET ROLE/SESSION AUTHORIZATION, or it could trivially obtain the privileges of the session user. However, since there is in general no privilege checking for changes of session-local state, it is also possible for such a function to change settings in a way that might subvert later operations in the same session. Examples include changing search_path to cause an unexpected function to be called, or replacing an existing prepared statement with another one that will execute a function of the attacker's choosing. The present patch secures VACUUM, ANALYZE, and CREATE INDEX/REINDEX against these threats, which are the same places previously deemed to need protection against the SET ROLE issue. GUC changes are still allowed, since there are many useful cases for that, but we prevent security problems by forcing a rollback of any GUC change after completing the operation. Other cases are handled by throwing an error if any change is attempted; these include temp table creation, closing a cursor, and creating or deleting a prepared statement. (In 7.4, the infrastructure to roll back GUC changes doesn't exist, so we settle for rejecting changes of "search_path" in these contexts.) Original report and patch by Gurjeet Singh, additional analysis by Tom Lane. Security: CVE-2009-4136
2009-12-09 22:57:51 +01:00
/*
* Security check: disallow creating temp tables from security-restricted
* code. This is needed because calling code might not expect untrusted
* tables to appear in pg_temp at the front of its search path.
*/
Generalize concept of temporary relations to "relation persistence". This commit replaces pg_class.relistemp with pg_class.relpersistence; and also modifies the RangeVar node type to carry relpersistence rather than istemp. It also removes removes rd_istemp from RelationData and instead performs the correct computation based on relpersistence. For clarity, we add three new macros: RelationNeedsWAL(), RelationUsesLocalBuffers(), and RelationUsesTempNamespace(), so that we can clarify the purpose of each check that previous depended on rd_istemp. This is intended as infrastructure for the upcoming unlogged tables patch, as well as for future possible work on global temporary tables.
2010-12-13 18:34:26 +01:00
if (stmt->relation->relpersistence == RELPERSISTENCE_TEMP
&& InSecurityRestrictedOperation())
Prevent indirect security attacks via changing session-local state within an allegedly immutable index function. It was previously recognized that we had to prevent such a function from executing SET/RESET ROLE/SESSION AUTHORIZATION, or it could trivially obtain the privileges of the session user. However, since there is in general no privilege checking for changes of session-local state, it is also possible for such a function to change settings in a way that might subvert later operations in the same session. Examples include changing search_path to cause an unexpected function to be called, or replacing an existing prepared statement with another one that will execute a function of the attacker's choosing. The present patch secures VACUUM, ANALYZE, and CREATE INDEX/REINDEX against these threats, which are the same places previously deemed to need protection against the SET ROLE issue. GUC changes are still allowed, since there are many useful cases for that, but we prevent security problems by forcing a rollback of any GUC change after completing the operation. Other cases are handled by throwing an error if any change is attempted; these include temp table creation, closing a cursor, and creating or deleting a prepared statement. (In 7.4, the infrastructure to roll back GUC changes doesn't exist, so we settle for rejecting changes of "search_path" in these contexts.) Original report and patch by Gurjeet Singh, additional analysis by Tom Lane. Security: CVE-2009-4136
2009-12-09 22:57:51 +01:00
ereport(ERROR,
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
errmsg("cannot create temporary table within security-restricted operation")));
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
/*
Create a GUC parameter temp_tablespaces that allows selection of the 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.
2007-06-03 19:08:34 +02:00
* Select tablespace to use. If not specified, use default tablespace
Create 'default_tablespace' GUC variable that supplies a TABLESPACE clause implicitly whenever one is not given explicitly. Remove concept of a schema having an associated tablespace, and simplify the rules for selecting a default tablespace for a table or index. It's now just (a) explicit TABLESPACE clause; (b) default_tablespace if that's not an empty string; (c) database's default. This will allow pg_dump to use SET commands instead of tablespace clauses to determine object locations (but I didn't actually make it do so). All per recent discussions.
2004-11-05 20:17:13 +01:00
* (which may in turn default to database's default).
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
*/
if (stmt->tablespacename)
{
Standardize get_whatever_oid functions for object types with unqualified names. - Add a missing_ok parameter to get_tablespace_oid. - Avoid duplicating get_tablespace_od guts in objectNamesToOids. - Add a missing_ok parameter to get_database_oid. - Replace get_roleid and get_role_checked with get_role_oid. - Add get_namespace_oid, get_language_oid, get_am_oid. - Refactor existing code to use new interfaces. Thanks to KaiGai Kohei for the review.
2010-08-05 16:45:09 +02:00
tablespaceId = get_tablespace_oid(stmt->tablespacename, false);
Create 'default_tablespace' GUC variable that supplies a TABLESPACE clause implicitly whenever one is not given explicitly. Remove concept of a schema having an associated tablespace, and simplify the rules for selecting a default tablespace for a table or index. It's now just (a) explicit TABLESPACE clause; (b) default_tablespace if that's not an empty string; (c) database's default. This will allow pg_dump to use SET commands instead of tablespace clauses to determine object locations (but I didn't actually make it do so). All per recent discussions.
2004-11-05 20:17:13 +01:00
}
else
{
Generalize concept of temporary relations to "relation persistence". This commit replaces pg_class.relistemp with pg_class.relpersistence; and also modifies the RangeVar node type to carry relpersistence rather than istemp. It also removes removes rd_istemp from RelationData and instead performs the correct computation based on relpersistence. For clarity, we add three new macros: RelationNeedsWAL(), RelationUsesLocalBuffers(), and RelationUsesTempNamespace(), so that we can clarify the purpose of each check that previous depended on rd_istemp. This is intended as infrastructure for the upcoming unlogged tables patch, as well as for future possible work on global temporary tables.
2010-12-13 18:34:26 +01:00
tablespaceId = GetDefaultTablespace(stmt->relation->relpersistence);
Create 'default_tablespace' GUC variable that supplies a TABLESPACE clause implicitly whenever one is not given explicitly. Remove concept of a schema having an associated tablespace, and simplify the rules for selecting a default tablespace for a table or index. It's now just (a) explicit TABLESPACE clause; (b) default_tablespace if that's not an empty string; (c) database's default. This will allow pg_dump to use SET commands instead of tablespace clauses to determine object locations (but I didn't actually make it do so). All per recent discussions.
2004-11-05 20:17:13 +01:00
/* note InvalidOid is OK in this case */
}
/* Check permissions except when using database's default */
Fix CREATE TABLE ... LIKE ... INCLUDING INDEXES to not cause unwanted tablespace permissions failures when copying an index that is in the database's default tablespace. A side-effect of the change is that explicitly specifying the default tablespace no longer triggers a permissions check; this is not how it was done in pre-8.3 releases but is argued to be more consistent. Per bug #3921 from Andrew Gilligan. (Note: I argued in the subsequent discussion that maybe LIKE shouldn't copy index tablespaces at all, but since no one indicated agreement with that idea, I've refrained from doing it.)
2008-02-07 18:09:51 +01:00
if (OidIsValid(tablespaceId) && tablespaceId != MyDatabaseTableSpace)
Create 'default_tablespace' GUC variable that supplies a TABLESPACE clause implicitly whenever one is not given explicitly. Remove concept of a schema having an associated tablespace, and simplify the rules for selecting a default tablespace for a table or index. It's now just (a) explicit TABLESPACE clause; (b) default_tablespace if that's not an empty string; (c) database's default. This will allow pg_dump to use SET commands instead of tablespace clauses to determine object locations (but I didn't actually make it do so). All per recent discussions.
2004-11-05 20:17:13 +01:00
{
AclResult aclresult;
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
aclresult = pg_tablespace_aclcheck(tablespaceId, GetUserId(),
ACL_CREATE);
if (aclresult != ACLCHECK_OK)
aclcheck_error(aclresult, ACL_KIND_TABLESPACE,
Create 'default_tablespace' GUC variable that supplies a TABLESPACE clause implicitly whenever one is not given explicitly. Remove concept of a schema having an associated tablespace, and simplify the rules for selecting a default tablespace for a table or index. It's now just (a) explicit TABLESPACE clause; (b) default_tablespace if that's not an empty string; (c) database's default. This will allow pg_dump to use SET commands instead of tablespace clauses to determine object locations (but I didn't actually make it do so). All per recent discussions.
2004-11-05 20:17:13 +01:00
get_tablespace_name(tablespaceId));
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
}
Create a "relation mapping" infrastructure to support changing the relfilenodes of shared or nailed system catalogs. This has two key benefits: * The new CLUSTER-based VACUUM FULL can be applied safely to all catalogs. * We no longer have to use an unsafe reindex-in-place approach for reindexing shared catalogs. CLUSTER on nailed catalogs now works too, although I left it disabled on shared catalogs because the resulting pg_index.indisclustered update would only be visible in one database. Since reindexing shared system catalogs is now fully transactional and crash-safe, the former special cases in REINDEX behavior have been removed; shared catalogs are treated the same as non-shared. This commit does not do anything about the recently-discussed problem of deadlocks between VACUUM FULL/CLUSTER on a system catalog and other concurrent queries; will address that in a separate patch. As a stopgap, parallel_schedule has been tweaked to run vacuum.sql by itself, to avoid such failures during the regression tests.
2010-02-07 21:48:13 +01:00
/* In all cases disallow placing user relations in pg_global */
if (tablespaceId == GLOBALTABLESPACE_OID)
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("only shared relations can be placed in pg_global tablespace")));
Fix failure of "ALTER TABLE t ADD COLUMN c serial" when done by non-owner. The implicitly created sequence was created as owned by the current user, who could be different from the table owner, eg if current user is a superuser or some member of the table's owning role. This caused sanity checks in the SEQUENCE OWNED BY code to spit up. Although possibly we don't need those sanity checks, the safest fix seems to be to make sure the implicit sequence is assigned the same owner role as the table has. (We still do all permissions checks as the current user, however.) Per report from Josh Berkus. Back-patch to 9.0. The bug goes back to the invention of SEQUENCE OWNED BY in 8.2, but the fix requires an API change for DefineRelation(), which seems to have potential for breaking third-party code if done in a minor release. Given the lack of prior complaints, it's probably not worth fixing in the stable branches.
2010-08-18 20:35:21 +02:00
/* Identify user ID that will own the table */
if (!OidIsValid(ownerId))
ownerId = GetUserId();
Create a GUC parameter temp_tablespaces that allows selection of the 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.
2007-06-03 19:08:34 +02:00
/*
* Parse and validate reloptions, if any.
*/
Allow reloption names to have qualifiers, initially supporting a TOAST qualifier, and add support for this in pg_dump. This allows TOAST tables to have user-defined fillfactor, and will also enable us to move the autovacuum parameters to reloptions without taking away the possibility of setting values for TOAST tables.
2009-02-02 20:31:40 +01:00
reloptions = transformRelOptions((Datum) 0, stmt->options, NULL, validnsps,
true, false);
Create a GUC parameter temp_tablespaces that allows selection of the 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.
2007-06-03 19:08:34 +02:00
(void) heap_reloptions(relkind, reloptions, true);
Type table feature This adds the CREATE TABLE name OF type command, per SQL standard.
2010-01-29 00:21:13 +01:00
if (stmt->ofTypename)
Add support for privileges on types This adds support for the more or less SQL-conforming USAGE privilege on types and domains. The intent is to be able restrict which users can create dependencies on types, which restricts the way in which owners can alter types. reviewed by Yeb Havinga
2011-12-19 23:05:19 +01:00
{
AclResult aclresult;
Refactor typenameTypeId() Split the old typenameTypeId() into two functions: A new typenameTypeId() that returns only a type OID, and typenameTypeIdAndMod() that returns type OID and typmod. This isolates call sites better that actually care about the typmod.
2010-10-25 20:40:46 +02:00
ofTypeId = typenameTypeId(NULL, stmt->ofTypename);
Add support for privileges on types This adds support for the more or less SQL-conforming USAGE privilege on types and domains. The intent is to be able restrict which users can create dependencies on types, which restricts the way in which owners can alter types. reviewed by Yeb Havinga
2011-12-19 23:05:19 +01:00
aclresult = pg_type_aclcheck(ofTypeId, GetUserId(), ACL_USAGE);
if (aclresult != ACLCHECK_OK)
Improve reporting of permission errors for array types Because permissions are assigned to element types, not array types, complaining about permission denied on an array type would be misleading to users. So adjust the reporting to refer to the element type instead. In order not to duplicate the required logic in two dozen places, refactor the permission denied reporting for types a bit. pointed out by Yeb Havinga during the review of the type privilege feature
2012-06-15 21:55:03 +02:00
aclcheck_error_type(aclresult, ofTypeId);
Add support for privileges on types This adds support for the more or less SQL-conforming USAGE privilege on types and domains. The intent is to be able restrict which users can create dependencies on types, which restricts the way in which owners can alter types. reviewed by Yeb Havinga
2011-12-19 23:05:19 +01:00
}
Type table feature This adds the CREATE TABLE name OF type command, per SQL standard.
2010-01-29 00:21:13 +01:00
else
ofTypeId = InvalidOid;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Look up inheritance ancestors and generate relation schema, including
* inherited attributes.
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
*/
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
schema = MergeAttributes(schema, stmt->inhRelations,
Generalize concept of temporary relations to "relation persistence". This commit replaces pg_class.relistemp with pg_class.relpersistence; and also modifies the RangeVar node type to carry relpersistence rather than istemp. It also removes removes rd_istemp from RelationData and instead performs the correct computation based on relpersistence. For clarity, we add three new macros: RelationNeedsWAL(), RelationUsesLocalBuffers(), and RelationUsesTempNamespace(), so that we can clarify the purpose of each check that previous depended on rd_istemp. This is intended as infrastructure for the upcoming unlogged tables patch, as well as for future possible work on global temporary tables.
2010-12-13 18:34:26 +01:00
stmt->relation->relpersistence,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
&inheritOids, &old_constraints, &parentOidCount);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* Create a tuple descriptor from the relation schema. Note that this
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
* deals with column names, types, and NOT NULL constraints, but not
* default values or CHECK constraints; we handle those below.
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*/
descriptor = BuildDescForRelation(schema);
Code review for HeapTupleHeader changes. Add version number to page headers (overlaying low byte of page size) and add HEAP_HASOID bit to t_infomask, per earlier discussion. Simplify scheme for overlaying fields in tuple header (no need for cmax to live in more than one place). Don't try to clear infomask status bits in tqual.c --- not safe to do it there. Don't try to force output table of a SELECT INTO to have OIDs, either. Get rid of unnecessarily complex three-state scheme for TupleDesc.tdhasoids, which has already caused one recent failure. Improve documentation.
2002-09-02 03:05:06 +02:00
Clean up the mess around EXPLAIN and materialized views. Revert the matview-related changes in explain.c's API, as per recent complaint from Robert Haas. The reason for these appears to have been principally some ill-considered choices around having intorel_startup do what ought to be parse-time checking, plus a poor arrangement for passing it the view parsetree it needs to store into pg_rewrite when creating a materialized view. Do the latter by having parse analysis stick a copy into the IntoClause, instead of doing it at runtime. (On the whole, I seriously question the choice to represent CREATE MATERIALIZED VIEW as a variant of SELECT INTO/CREATE TABLE AS, because that means injecting even more complexity into what was already a horrid legacy kluge. However, I didn't go so far as to rethink that choice ... yet.) I also moved several error checks into matview parse analysis, and made the check for external Params in a matview more accurate. In passing, clean things up a bit more around interpretOidsOption(), and fix things so that we can use that to force no-oids for views, sequences, etc, thereby eliminating the need to cons up "oids = false" options when creating them. catversion bump due to change in IntoClause. (I wonder though if we really need readfuncs/outfuncs support for IntoClause anymore.)
2013-04-13 01:25:20 +02:00
localHasOids = interpretOidsOption(stmt->options,
(relkind == RELKIND_RELATION ||
relkind == RELKIND_FOREIGN_TABLE));
Upgrade ALTER TABLE DROP COLUMN so that it can drop an OID column, and remove separate implementation of ALTER TABLE SET WITHOUT OIDS in favor of doing a regular DROP. Also, cause CREATE TABLE to account completely correctly for the inheritance status of the OID column. This fixes problems with dropping OID columns that have dependencies, as noted by Christopher Kings-Lynne, as well as making sure that you can't drop an OID column that was inherited from a parent.
2004-03-23 20:35:17 +01:00
descriptor->tdhasoid = (localHasOids || parentOidCount > 0);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
/*
* Find columns with default values and prepare for insertion of the
* defaults. Pre-cooked (that is, inherited) defaults go into a list of
* CookedConstraint structs that we'll pass to heap_create_with_catalog,
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* while raw defaults go into a list of RawColumnDefault structs that will
* be processed by AddRelationNewConstraints. (We can't deal with raw
* expressions until we can do transformExpr.)
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
*
* We can set the atthasdef flags now in the tuple descriptor; this just
* saves StoreAttrDefault from having to do an immediate update of the
* pg_attribute rows.
*/
rawDefaults = NIL;
cookedDefaults = NIL;
attnum = 0;
foreach(listptr, schema)
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
{
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
ColumnDef *colDef = lfirst(listptr);
fix_parsetree_attnums was not nearly smart enough about walking parse trees. Also rewrite find_all_inheritors() in a more intelligible style.
1999-12-14 04:35:28 +01:00
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
attnum++;
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
if (colDef->raw_default != NULL)
Code review for LIKE INCLUDING CONSTRAINTS patch --- improve comments, don't cheat on the raw-vs-cooked status of a constraint.
2006-10-11 18:42:59 +02:00
{
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
RawColumnDefault *rawEnt;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
Assert(colDef->cooked_default == NULL);
rawEnt = (RawColumnDefault *) palloc(sizeof(RawColumnDefault));
rawEnt->attnum = attnum;
rawEnt->raw_default = colDef->raw_default;
rawDefaults = lappend(rawDefaults, rawEnt);
descriptor->attrs[attnum - 1]->atthasdef = true;
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
}
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
else if (colDef->cooked_default != NULL)
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
{
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
CookedConstraint *cooked;
cooked = (CookedConstraint *) palloc(sizeof(CookedConstraint));
cooked->contype = CONSTR_DEFAULT;
cooked->name = NULL;
cooked->attnum = attnum;
Change CREATE TABLE so that column default expressions coming from different inheritance parent tables are compared using equal(), instead of doing strcmp() on the nodeToString representation. The old implementation was always a tad cheesy, and it finally fails completely as of 8.4, now that the node tree might contain syntax location information. equal() knows it's supposed to ignore those fields, but strcmp() hardly can. Per recent report from Scott Ribe.
2009-10-06 02:55:26 +02:00
cooked->expr = colDef->cooked_default;
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
cooked->skip_validation = false;
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
cooked->is_local = true; /* not used for defaults */
cooked->inhcount = 0; /* ditto */
Recast "ONLY" column CHECK constraints as NO INHERIT The original syntax wasn't universally loved, and it didn't allow its usage in CREATE TABLE, only ALTER TABLE. It now works everywhere, and it also allows using ALTER TABLE ONLY to add an uninherited CHECK constraint, per discussion. The pg_constraint column has accordingly been renamed connoinherit. This commit partly reverts some of the changes in 61d81bd28dbec65a6b144e0cd3d0bfe25913c3ac, particularly some pg_dump and psql bits, because now pg_get_constraintdef includes the necessary NO INHERIT within the constraint definition. Author: Nikhil Sontakke Some tweaks by me
2012-04-21 04:46:20 +02:00
cooked->is_no_inherit = false;
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
cookedDefaults = lappend(cookedDefaults, cooked);
descriptor->attrs[attnum - 1]->atthasdef = true;
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
}
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
/*
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* Create the relation. Inherited defaults and constraints are passed in
* for immediate handling --- since they don't need parsing, they can be
* stored immediately.
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
*/
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
relationId = heap_create_with_catalog(relname,
namespaceId,
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
tablespaceId,
First phase of project to use fixed OIDs for all system catalogs and indexes. Extend the macros in include/catalog/*.h to carry the info about hand-assigned OIDs, and adjust the genbki script and bootstrap code to make the relations actually get those OIDs. Remove the small number of RelOid_pg_foo macros that we had in favor of a complete set named like the catname.h and indexing.h macros. Next phase will get rid of internal use of names for looking up catalogs and indexes; but this completes the changes forcing an initdb, so it looks like a good place to commit. Along the way, I made the shared relations (pg_database etc) not be 'bootstrap' relations any more, so as to reduce the number of hardwired entries and simplify changing those relations in future. I'm not sure whether they ever really needed to be handled as bootstrap relations, but it seems to work fine to not do so now.
2005-04-14 03:38:22 +02:00
InvalidOid,
Extend the BKI infrastructure to allow system catalogs to be given hand-assigned rowtype OIDs, even when they are not "bootstrapped" catalogs that have handmade type rows in pg_type.h. Give pg_database such an OID. Restore the availability of C macros for the rowtype OIDs of the bootstrapped catalogs. (These macros are now in the individual catalogs' .h files, though, not in pg_type.h.) This commit doesn't do anything especially useful by itself, but it's necessary infrastructure for reverting some ill-considered changes in relcache.c.
2009-09-27 00:42:03 +02:00
InvalidOid,
Type table feature This adds the CREATE TABLE name OF type command, per SQL standard.
2010-01-29 00:21:13 +01:00
ofTypeId,
Fix failure of "ALTER TABLE t ADD COLUMN c serial" when done by non-owner. The implicitly created sequence was created as owned by the current user, who could be different from the table owner, eg if current user is a superuser or some member of the table's owning role. This caused sanity checks in the SEQUENCE OWNED BY code to spit up. Although possibly we don't need those sanity checks, the safest fix seems to be to make sure the implicit sequence is assigned the same owner role as the table has. (We still do all permissions checks as the current user, however.) Per report from Josh Berkus. Back-patch to 9.0. The bug goes back to the invention of SEQUENCE OWNED BY in 8.2, but the fix requires an API change for DefineRelation(), which seems to have potential for breaking third-party code if done in a minor release. Given the lack of prior complaints, it's probably not worth fixing in the stable branches.
2010-08-18 20:35:21 +02:00
ownerId,
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
descriptor,
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
list_concat(cookedDefaults,
old_constraints),
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
relkind,
Generalize concept of temporary relations to "relation persistence". This commit replaces pg_class.relistemp with pg_class.relpersistence; and also modifies the RangeVar node type to carry relpersistence rather than istemp. It also removes removes rd_istemp from RelationData and instead performs the correct computation based on relpersistence. For clarity, we add three new macros: RelationNeedsWAL(), RelationUsesLocalBuffers(), and RelationUsesTempNamespace(), so that we can clarify the purpose of each check that previous depended on rd_istemp. This is intended as infrastructure for the upcoming unlogged tables patch, as well as for future possible work on global temporary tables.
2010-12-13 18:34:26 +01:00
stmt->relation->relpersistence,
Support toasting of shared system relations, and provide toast tables for pg_database, pg_shadow, pg_group, all of which now have potentially-long fields. Along the way, get rid of SharedSystemRelationNames list: shared rels are now identified in their include/pg_catalog/*.h files by a BKI_SHARED_RELATION macro, while indexes and toast rels inherit sharedness automatically from their parent table. Fix some bugs with failure to detoast pg_group.grolist during ALTER GROUP.
2002-04-27 23:24:34 +02:00
false,
Create a "relation mapping" infrastructure to support changing the relfilenodes of shared or nailed system catalogs. This has two key benefits: * The new CLUSTER-based VACUUM FULL can be applied safely to all catalogs. * We no longer have to use an unsafe reindex-in-place approach for reindexing shared catalogs. CLUSTER on nailed catalogs now works too, although I left it disabled on shared catalogs because the resulting pg_index.indisclustered update would only be visible in one database. Since reindexing shared system catalogs is now fully transactional and crash-safe, the former special cases in REINDEX behavior have been removed; shared catalogs are treated the same as non-shared. This commit does not do anything about the recently-discussed problem of deadlocks between VACUUM FULL/CLUSTER on a system catalog and other concurrent queries; will address that in a separate patch. As a stopgap, parallel_schedule has been tweaked to run vacuum.sql by itself, to avoid such failures during the regression tests.
2010-02-07 21:48:13 +01:00
false,
Upgrade ALTER TABLE DROP COLUMN so that it can drop an OID column, and remove separate implementation of ALTER TABLE SET WITHOUT OIDS in favor of doing a regular DROP. Also, cause CREATE TABLE to account completely correctly for the inheritance status of the OID column. This fixes problems with dropping OID columns that have dependencies, as noted by Christopher Kings-Lynne, as well as making sure that you can't drop an OID column that was inherited from a parent.
2004-03-23 20:35:17 +01:00
localHasOids,
parentOidCount,
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
stmt->oncommit,
Code review for FILLFACTOR patch. Change WITH grammar as per earlier 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.
2006-07-04 00:45:41 +02:00
reloptions,
Create an ALTER DEFAULT PRIVILEGES command, which allows users to adjust the privileges that will be applied to subsequently-created objects. Such adjustments are always per owning role, and can be restricted to objects created in particular schemas too. A notable benefit is that users can override the traditional default privilege settings, eg, the PUBLIC EXECUTE privilege traditionally granted by default for functions. Petr Jelinek
2009-10-05 21:24:49 +02:00
true,
Add context info to OAT_POST_CREATE security hook ... and have sepgsql use it to determine whether to check permissions during certain operations. Indexes that are being created as a result of REINDEX, for instance, do not need to have their permissions checked; they were already checked when the index was created. Author: KaiGai Kohei, slightly revised by me
2012-10-23 23:07:26 +02:00
allowSystemTableMods,
false);
CREATE TABLE IF NOT EXISTS. Reviewed by Bernd Helmle.
2010-07-26 01:21:22 +02:00
/* Store inheritance information for new rel. */
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
StoreCatalogInheritance(relationId, inheritOids);
Break transformCreateStmt() into multiple routines and make transformAlterStmt() use these routines, instead of having lots of duplicate (not to mention should-have-been-duplicate) code. Adding a column with a CHECK constraint actually works now, and the tests to reject unsupported DEFAULT and NOT NULL clauses actually fire now. ALTER TABLE ADD PRIMARY KEY works, modulo having to have created the column(s) NOT NULL already.
2001-10-12 02:07:15 +02:00
/*
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
* We must bump the command counter to make the newly-created relation
* tuple visible for opening.
*/
CommandCounterIncrement();
/*
* Open the new relation and acquire exclusive lock on it. This isn't
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* really necessary for locking out other backends (since they can't see
* the new rel anyway until we commit), but it keeps the lock manager from
* complaining about deadlock risks.
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*/
Code review for standalone composite types, query-specified composite types, SRFs. Not happy with memory management yet, but I'll commit these other changes.
2002-08-29 02:17:06 +02:00
rel = relation_open(relationId, AccessExclusiveLock);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Now add any newly specified column default values and CHECK constraints
* to the new relation. These are passed to us in the form of raw
* parsetrees; we need to transform them to executable expression trees
* before they can be added. The most convenient way to do that is to
* apply the parser's transformExpr routine, but transformExpr doesn't
* work unless we have a pre-existing relation. So, the transformation has
* to be postponed to this final step of CREATE TABLE.
Change SearchSysCache coding conventions so that a reference count is maintained for each cache entry. A cache entry will not be freed until the matching ReleaseSysCache call has been executed. This eliminates worries about cache entries getting dropped while still in use. See my posting to pg-hackers of even date for more info.
2000-11-16 23:30:52 +01:00
*/
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
if (rawDefaults || stmt->constraints)
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
AddRelationNewConstraints(rel, rawDefaults, stmt->constraints,
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
true, true, false);
Automatically create toast tables on ALTER TABLE ... ADD COLUMN and SELECT ... INTO ... too. Jan
2000-07-05 15:22:25 +02:00
Break transformCreateStmt() into multiple routines and make transformAlterStmt() use these routines, instead of having lots of duplicate (not to mention should-have-been-duplicate) code. Adding a column with a CHECK constraint actually works now, and the tests to reject unsupported DEFAULT and NOT NULL clauses actually fire now. ALTER TABLE ADD PRIMARY KEY works, modulo having to have created the column(s) NOT NULL already.
2001-10-12 02:07:15 +02:00
/*
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
* Clean up. We keep lock on new relation (although it shouldn't be
* visible to anyone else anyway, until commit).
Break transformCreateStmt() into multiple routines and make transformAlterStmt() use these routines, instead of having lots of duplicate (not to mention should-have-been-duplicate) code. Adding a column with a CHECK constraint actually works now, and the tests to reject unsupported DEFAULT and NOT NULL clauses actually fire now. ALTER TABLE ADD PRIMARY KEY works, modulo having to have created the column(s) NOT NULL already.
2001-10-12 02:07:15 +02:00
*/
Code review for standalone composite types, query-specified composite types, SRFs. Not happy with memory management yet, but I'll commit these other changes.
2002-08-29 02:17:06 +02:00
relation_close(rel, NoLock);
Break transformCreateStmt() into multiple routines and make transformAlterStmt() use these routines, instead of having lots of duplicate (not to mention should-have-been-duplicate) code. Adding a column with a CHECK constraint actually works now, and the tests to reject unsupported DEFAULT and NOT NULL clauses actually fire now. ALTER TABLE ADD PRIMARY KEY works, modulo having to have created the column(s) NOT NULL already.
2001-10-12 02:07:15 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
return relationId;
}
Break transformCreateStmt() into multiple routines and make transformAlterStmt() use these routines, instead of having lots of duplicate (not to mention should-have-been-duplicate) code. Adding a column with a CHECK constraint actually works now, and the tests to reject unsupported DEFAULT and NOT NULL clauses actually fire now. ALTER TABLE ADD PRIMARY KEY works, modulo having to have created the column(s) NOT NULL already.
2001-10-12 02:07:15 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
Refactor the handling of the various DropStmt variants so that when multiple objects are specified, we drop them all in a single performMultipleDeletions call. This makes the RESTRICT/CASCADE checks more relaxed: it's not counted as a cascade if one of the later objects has a dependency on an earlier one. NOTICE messages about such cases go away, too. In passing, fix the permissions check for DROP CONVERSION, which for some reason was never made role-aware, and omitted the namespace-owner exemption too. Alex Hunsaker, with further fiddling by me.
2008-06-14 20:04:34 +02:00
* Emit the right error or warning message for a "DROP" command issued on a
* non-existent relation
*/
static void
DropErrorMsgNonExistent(const char *relname, char rightkind, bool missing_ok)
{
const struct dropmsgstrings *rentry;
for (rentry = dropmsgstringarray; rentry->kind != '\0'; rentry++)
{
if (rentry->kind == rightkind)
{
if (!missing_ok)
{
ereport(ERROR,
(errcode(rentry->nonexistent_code),
errmsg(rentry->nonexistent_msg, relname)));
}
else
{
ereport(NOTICE, (errmsg(rentry->skipping_msg, relname)));
break;
}
}
}
Assert(rentry->kind != '\0'); /* Should be impossible */
}
/*
* Emit the right error message for a "DROP" command issued on a
* relation of the wrong type
*/
static void
DropErrorMsgWrongType(const char *relname, char wrongkind, char rightkind)
{
const struct dropmsgstrings *rentry;
const struct dropmsgstrings *wentry;
for (rentry = dropmsgstringarray; rentry->kind != '\0'; rentry++)
if (rentry->kind == rightkind)
break;
Assert(rentry->kind != '\0');
for (wentry = dropmsgstringarray; wentry->kind != '\0'; wentry++)
if (wentry->kind == wrongkind)
break;
/* wrongkind could be something we don't have in our table... */
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg(rentry->nota_msg, relname),
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
(wentry->kind != '\0') ? errhint("%s", _(wentry->drophint_msg)) : 0));
Refactor the handling of the various DropStmt variants so that when multiple objects are specified, we drop them all in a single performMultipleDeletions call. This makes the RESTRICT/CASCADE checks more relaxed: it's not counted as a cascade if one of the later objects has a dependency on an earlier one. NOTICE messages about such cases go away, too. In passing, fix the permissions check for DROP CONVERSION, which for some reason was never made role-aware, and omitted the namespace-owner exemption too. Alex Hunsaker, with further fiddling by me.
2008-06-14 20:04:34 +02:00
}
/*
* RemoveRelations
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
* Implements DROP TABLE, DROP INDEX, DROP SEQUENCE, DROP VIEW,
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
* DROP MATERIALIZED VIEW, DROP FOREIGN TABLE
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*/
void
Refactor the handling of the various DropStmt variants so that when multiple objects are specified, we drop them all in a single performMultipleDeletions call. This makes the RESTRICT/CASCADE checks more relaxed: it's not counted as a cascade if one of the later objects has a dependency on an earlier one. NOTICE messages about such cases go away, too. In passing, fix the permissions check for DROP CONVERSION, which for some reason was never made role-aware, and omitted the namespace-owner exemption too. Alex Hunsaker, with further fiddling by me.
2008-06-14 20:04:34 +02:00
RemoveRelations(DropStmt *drop)
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
{
Refactor the handling of the various DropStmt variants so that when multiple objects are specified, we drop them all in a single performMultipleDeletions call. This makes the RESTRICT/CASCADE checks more relaxed: it's not counted as a cascade if one of the later objects has a dependency on an earlier one. NOTICE messages about such cases go away, too. In passing, fix the permissions check for DROP CONVERSION, which for some reason was never made role-aware, and omitted the namespace-owner exemption too. Alex Hunsaker, with further fiddling by me.
2008-06-14 20:04:34 +02:00
ObjectAddresses *objects;
char relkind;
ListCell *cell;
Add DROP INDEX CONCURRENTLY [IF EXISTS], uses ShareUpdateExclusiveLock
2012-04-06 11:21:40 +02:00
int flags = 0;
LOCKMODE lockmode = AccessExclusiveLock;
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY. Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor choice of catalog state representation. The pg_index state for an index that's reached the final pre-drop stage was the same as the state for an index just created by CREATE INDEX CONCURRENTLY. This meant that the (necessary) change to make RelationGetIndexList ignore about-to-die indexes also made it ignore freshly-created indexes; which is catastrophic because the latter do need to be considered in HOT-safety decisions. Failure to do so leads to incorrect index entries and subsequently wrong results from queries depending on the concurrently-created index. To fix, add an additional boolean column "indislive" to pg_index, so that the freshly-created and about-to-die states can be distinguished. (This change obviously is only possible in HEAD. This patch will need to be back-patched, but in 9.2 we'll use a kluge consisting of overloading the formerly-impossible state of indisvalid = true and indisready = false.) In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index flag changes they make without exclusive lock on the index are made via heap_inplace_update() rather than a normal transactional update. The latter is not very safe because moving the pg_index tuple could result in concurrent SnapshotNow scans finding it twice or not at all, thus possibly resulting in index corruption. This is a pre-existing bug in CREATE INDEX CONCURRENTLY, which was copied into the DROP code. In addition, fix various places in the code that ought to check to make sure that the indexes they are manipulating are valid and/or ready as appropriate. These represent bugs that have existed since 8.2, since a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid index behind, and we ought not try to do anything that might fail with such an index. Also fix RelationReloadIndexInfo to ensure it copies all the pg_index columns that are allowed to change after initial creation. Previously we could have been left with stale values of some fields in an index relcache entry. It's not clear whether this actually had any user-visible consequences, but it's at least a bug waiting to happen. In addition, do some code and docs review for DROP INDEX CONCURRENTLY; some cosmetic code cleanup but mostly addition and revision of comments. This will need to be back-patched, but in a noticeably different form, so I'm committing it to HEAD before working on the back-patch. Problem reported by Amit Kapila, diagnosis by Pavan Deolassee, fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
/* DROP CONCURRENTLY uses a weaker lock, and has some restrictions */
Add DROP INDEX CONCURRENTLY [IF EXISTS], uses ShareUpdateExclusiveLock
2012-04-06 11:21:40 +02:00
if (drop->concurrent)
{
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY. Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor choice of catalog state representation. The pg_index state for an index that's reached the final pre-drop stage was the same as the state for an index just created by CREATE INDEX CONCURRENTLY. This meant that the (necessary) change to make RelationGetIndexList ignore about-to-die indexes also made it ignore freshly-created indexes; which is catastrophic because the latter do need to be considered in HOT-safety decisions. Failure to do so leads to incorrect index entries and subsequently wrong results from queries depending on the concurrently-created index. To fix, add an additional boolean column "indislive" to pg_index, so that the freshly-created and about-to-die states can be distinguished. (This change obviously is only possible in HEAD. This patch will need to be back-patched, but in 9.2 we'll use a kluge consisting of overloading the formerly-impossible state of indisvalid = true and indisready = false.) In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index flag changes they make without exclusive lock on the index are made via heap_inplace_update() rather than a normal transactional update. The latter is not very safe because moving the pg_index tuple could result in concurrent SnapshotNow scans finding it twice or not at all, thus possibly resulting in index corruption. This is a pre-existing bug in CREATE INDEX CONCURRENTLY, which was copied into the DROP code. In addition, fix various places in the code that ought to check to make sure that the indexes they are manipulating are valid and/or ready as appropriate. These represent bugs that have existed since 8.2, since a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid index behind, and we ought not try to do anything that might fail with such an index. Also fix RelationReloadIndexInfo to ensure it copies all the pg_index columns that are allowed to change after initial creation. Previously we could have been left with stale values of some fields in an index relcache entry. It's not clear whether this actually had any user-visible consequences, but it's at least a bug waiting to happen. In addition, do some code and docs review for DROP INDEX CONCURRENTLY; some cosmetic code cleanup but mostly addition and revision of comments. This will need to be back-patched, but in a noticeably different form, so I'm committing it to HEAD before working on the back-patch. Problem reported by Amit Kapila, diagnosis by Pavan Deolassee, fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
flags |= PERFORM_DELETION_CONCURRENTLY;
Add DROP INDEX CONCURRENTLY [IF EXISTS], uses ShareUpdateExclusiveLock
2012-04-06 11:21:40 +02:00
lockmode = ShareUpdateExclusiveLock;
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY. Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor choice of catalog state representation. The pg_index state for an index that's reached the final pre-drop stage was the same as the state for an index just created by CREATE INDEX CONCURRENTLY. This meant that the (necessary) change to make RelationGetIndexList ignore about-to-die indexes also made it ignore freshly-created indexes; which is catastrophic because the latter do need to be considered in HOT-safety decisions. Failure to do so leads to incorrect index entries and subsequently wrong results from queries depending on the concurrently-created index. To fix, add an additional boolean column "indislive" to pg_index, so that the freshly-created and about-to-die states can be distinguished. (This change obviously is only possible in HEAD. This patch will need to be back-patched, but in 9.2 we'll use a kluge consisting of overloading the formerly-impossible state of indisvalid = true and indisready = false.) In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index flag changes they make without exclusive lock on the index are made via heap_inplace_update() rather than a normal transactional update. The latter is not very safe because moving the pg_index tuple could result in concurrent SnapshotNow scans finding it twice or not at all, thus possibly resulting in index corruption. This is a pre-existing bug in CREATE INDEX CONCURRENTLY, which was copied into the DROP code. In addition, fix various places in the code that ought to check to make sure that the indexes they are manipulating are valid and/or ready as appropriate. These represent bugs that have existed since 8.2, since a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid index behind, and we ought not try to do anything that might fail with such an index. Also fix RelationReloadIndexInfo to ensure it copies all the pg_index columns that are allowed to change after initial creation. Previously we could have been left with stale values of some fields in an index relcache entry. It's not clear whether this actually had any user-visible consequences, but it's at least a bug waiting to happen. In addition, do some code and docs review for DROP INDEX CONCURRENTLY; some cosmetic code cleanup but mostly addition and revision of comments. This will need to be back-patched, but in a noticeably different form, so I'm committing it to HEAD before working on the back-patch. Problem reported by Amit Kapila, diagnosis by Pavan Deolassee, fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
Assert(drop->removeType == OBJECT_INDEX);
if (list_length(drop->objects) != 1)
Add DROP INDEX CONCURRENTLY [IF EXISTS], uses ShareUpdateExclusiveLock
2012-04-06 11:21:40 +02:00
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("DROP INDEX CONCURRENTLY does not support dropping multiple objects")));
if (drop->behavior == DROP_CASCADE)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
errmsg("DROP INDEX CONCURRENTLY does not support CASCADE")));
Add DROP INDEX CONCURRENTLY [IF EXISTS], uses ShareUpdateExclusiveLock
2012-04-06 11:21:40 +02:00
}
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
Refactor the handling of the various DropStmt variants so that when multiple objects are specified, we drop them all in a single performMultipleDeletions call. This makes the RESTRICT/CASCADE checks more relaxed: it's not counted as a cascade if one of the later objects has a dependency on an earlier one. NOTICE messages about such cases go away, too. In passing, fix the permissions check for DROP CONVERSION, which for some reason was never made role-aware, and omitted the namespace-owner exemption too. Alex Hunsaker, with further fiddling by me.
2008-06-14 20:04:34 +02:00
/*
* First we identify all the relations, then we delete them in a single
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* performMultipleDeletions() call. This is to avoid unwanted DROP
* RESTRICT errors if one of the relations depends on another.
Refactor the handling of the various DropStmt variants so that when multiple objects are specified, we drop them all in a single performMultipleDeletions call. This makes the RESTRICT/CASCADE checks more relaxed: it's not counted as a cascade if one of the later objects has a dependency on an earlier one. NOTICE messages about such cases go away, too. In passing, fix the permissions check for DROP CONVERSION, which for some reason was never made role-aware, and omitted the namespace-owner exemption too. Alex Hunsaker, with further fiddling by me.
2008-06-14 20:04:34 +02:00
*/
/* Determine required relkind */
switch (drop->removeType)
{
case OBJECT_TABLE:
relkind = RELKIND_RELATION;
break;
case OBJECT_INDEX:
relkind = RELKIND_INDEX;
break;
case OBJECT_SEQUENCE:
relkind = RELKIND_SEQUENCE;
break;
case OBJECT_VIEW:
relkind = RELKIND_VIEW;
break;
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
case OBJECT_MATVIEW:
relkind = RELKIND_MATVIEW;
break;
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
case OBJECT_FOREIGN_TABLE:
relkind = RELKIND_FOREIGN_TABLE;
break;
Refactor the handling of the various DropStmt variants so that when multiple objects are specified, we drop them all in a single performMultipleDeletions call. This makes the RESTRICT/CASCADE checks more relaxed: it's not counted as a cascade if one of the later objects has a dependency on an earlier one. NOTICE messages about such cases go away, too. In passing, fix the permissions check for DROP CONVERSION, which for some reason was never made role-aware, and omitted the namespace-owner exemption too. Alex Hunsaker, with further fiddling by me.
2008-06-14 20:04:34 +02:00
default:
elog(ERROR, "unrecognized drop object type: %d",
(int) drop->removeType);
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
relkind = 0; /* keep compiler quiet */
Refactor the handling of the various DropStmt variants so that when multiple objects are specified, we drop them all in a single performMultipleDeletions call. This makes the RESTRICT/CASCADE checks more relaxed: it's not counted as a cascade if one of the later objects has a dependency on an earlier one. NOTICE messages about such cases go away, too. In passing, fix the permissions check for DROP CONVERSION, which for some reason was never made role-aware, and omitted the namespace-owner exemption too. Alex Hunsaker, with further fiddling by me.
2008-06-14 20:04:34 +02:00
break;
}
/* Lock and validate each relation; build a list of object addresses */
objects = new_object_addresses();
foreach(cell, drop->objects)
{
RangeVar *rel = makeRangeVarFromNameList((List *) lfirst(cell));
Oid relOid;
ObjectAddress obj;
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
struct DropRelationCallbackState state;
Refactor the handling of the various DropStmt variants so that when multiple objects are specified, we drop them all in a single performMultipleDeletions call. This makes the RESTRICT/CASCADE checks more relaxed: it's not counted as a cascade if one of the later objects has a dependency on an earlier one. NOTICE messages about such cases go away, too. In passing, fix the permissions check for DROP CONVERSION, which for some reason was never made role-aware, and omitted the namespace-owner exemption too. Alex Hunsaker, with further fiddling by me.
2008-06-14 20:04:34 +02:00
/*
* These next few steps are a great deal like relation_openrv, but we
* don't bother building a relcache entry since we don't need it.
*
* Check for shared-cache-inval messages before trying to access the
* relation. This is needed to cover the case where the name
* identifies a rel that has been dropped and recreated since the
* start of our transaction: if we don't flush the old syscache entry,
* then we'll latch onto that entry and suffer an error later.
*/
AcceptInvalidationMessages();
Improve table locking behavior in the face of current DDL. In the previous coding, callers were faced with an awkward choice: look up the name, do permissions checks, and then lock the table; or look up the name, lock the table, and then do permissions checks. The first choice was wrong because the results of the name lookup and permissions checks might be out-of-date by the time the table lock was acquired, while the second allowed a user with no privileges to interfere with access to a table by users who do have privileges (e.g. if a malicious backend queues up for an AccessExclusiveLock on a table on which AccessShareLock is already held, further attempts to access the table will be blocked until the AccessExclusiveLock is obtained and the malicious backend's transaction rolls back). To fix, allow callers of RangeVarGetRelid() to pass a callback which gets executed after performing the name lookup but before acquiring the relation lock. If the name lookup is retried (because invalidation messages are received), the callback will be re-executed as well, so we get the best of both worlds. RangeVarGetRelid() is renamed to RangeVarGetRelidExtended(); callers not wishing to supply a callback can continue to invoke it as RangeVarGetRelid(), which is now a macro. Since the only one caller that uses nowait = true now passes a callback anyway, the RangeVarGetRelid() macro defaults nowait as well. The callback can also be used for supplemental locking - for example, REINDEX INDEX needs to acquire the table lock before the index lock to reduce deadlock possibilities. There's a lot more work to be done here to fix all the cases where this can be a problem, but this commit provides the general infrastructure and fixes the following specific cases: REINDEX INDEX, REINDEX TABLE, LOCK TABLE, and and DROP TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE. Per discussion with Noah Misch and Alvaro Herrera.
2011-11-30 16:12:27 +01:00
/* Look up the appropriate relation using namespace search. */
state.relkind = relkind;
state.heapOid = InvalidOid;
Add DROP INDEX CONCURRENTLY [IF EXISTS], uses ShareUpdateExclusiveLock
2012-04-06 11:21:40 +02:00
state.concurrent = drop->concurrent;
relOid = RangeVarGetRelidExtended(rel, lockmode, true,
Improve table locking behavior in the face of current DDL. In the previous coding, callers were faced with an awkward choice: look up the name, do permissions checks, and then lock the table; or look up the name, lock the table, and then do permissions checks. The first choice was wrong because the results of the name lookup and permissions checks might be out-of-date by the time the table lock was acquired, while the second allowed a user with no privileges to interfere with access to a table by users who do have privileges (e.g. if a malicious backend queues up for an AccessExclusiveLock on a table on which AccessShareLock is already held, further attempts to access the table will be blocked until the AccessExclusiveLock is obtained and the malicious backend's transaction rolls back). To fix, allow callers of RangeVarGetRelid() to pass a callback which gets executed after performing the name lookup but before acquiring the relation lock. If the name lookup is retried (because invalidation messages are received), the callback will be re-executed as well, so we get the best of both worlds. RangeVarGetRelid() is renamed to RangeVarGetRelidExtended(); callers not wishing to supply a callback can continue to invoke it as RangeVarGetRelid(), which is now a macro. Since the only one caller that uses nowait = true now passes a callback anyway, the RangeVarGetRelid() macro defaults nowait as well. The callback can also be used for supplemental locking - for example, REINDEX INDEX needs to acquire the table lock before the index lock to reduce deadlock possibilities. There's a lot more work to be done here to fix all the cases where this can be a problem, but this commit provides the general infrastructure and fixes the following specific cases: REINDEX INDEX, REINDEX TABLE, LOCK TABLE, and and DROP TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE. Per discussion with Noah Misch and Alvaro Herrera.
2011-11-30 16:12:27 +01:00
false,
RangeVarCallbackForDropRelation,
(void *) &state);
Refactor the handling of the various DropStmt variants so that when multiple objects are specified, we drop them all in a single performMultipleDeletions call. This makes the RESTRICT/CASCADE checks more relaxed: it's not counted as a cascade if one of the later objects has a dependency on an earlier one. NOTICE messages about such cases go away, too. In passing, fix the permissions check for DROP CONVERSION, which for some reason was never made role-aware, and omitted the namespace-owner exemption too. Alex Hunsaker, with further fiddling by me.
2008-06-14 20:04:34 +02:00
/* Not there? */
if (!OidIsValid(relOid))
{
DropErrorMsgNonExistent(rel->relname, relkind, drop->missing_ok);
continue;
}
/* OK, we're ready to delete this one */
obj.classId = RelationRelationId;
obj.objectId = relOid;
obj.objectSubId = 0;
add_exact_object_address(&obj, objects);
}
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
Add DROP INDEX CONCURRENTLY [IF EXISTS], uses ShareUpdateExclusiveLock
2012-04-06 11:21:40 +02:00
performMultipleDeletions(objects, drop->behavior, flags);
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
Refactor the handling of the various DropStmt variants so that when multiple objects are specified, we drop them all in a single performMultipleDeletions call. This makes the RESTRICT/CASCADE checks more relaxed: it's not counted as a cascade if one of the later objects has a dependency on an earlier one. NOTICE messages about such cases go away, too. In passing, fix the permissions check for DROP CONVERSION, which for some reason was never made role-aware, and omitted the namespace-owner exemption too. Alex Hunsaker, with further fiddling by me.
2008-06-14 20:04:34 +02:00
free_object_addresses(objects);
Included all yacc and lex files into the distribution.
2000-01-16 21:05:00 +01:00
}
Improve table locking behavior in the face of current DDL. In the previous coding, callers were faced with an awkward choice: look up the name, do permissions checks, and then lock the table; or look up the name, lock the table, and then do permissions checks. The first choice was wrong because the results of the name lookup and permissions checks might be out-of-date by the time the table lock was acquired, while the second allowed a user with no privileges to interfere with access to a table by users who do have privileges (e.g. if a malicious backend queues up for an AccessExclusiveLock on a table on which AccessShareLock is already held, further attempts to access the table will be blocked until the AccessExclusiveLock is obtained and the malicious backend's transaction rolls back). To fix, allow callers of RangeVarGetRelid() to pass a callback which gets executed after performing the name lookup but before acquiring the relation lock. If the name lookup is retried (because invalidation messages are received), the callback will be re-executed as well, so we get the best of both worlds. RangeVarGetRelid() is renamed to RangeVarGetRelidExtended(); callers not wishing to supply a callback can continue to invoke it as RangeVarGetRelid(), which is now a macro. Since the only one caller that uses nowait = true now passes a callback anyway, the RangeVarGetRelid() macro defaults nowait as well. The callback can also be used for supplemental locking - for example, REINDEX INDEX needs to acquire the table lock before the index lock to reduce deadlock possibilities. There's a lot more work to be done here to fix all the cases where this can be a problem, but this commit provides the general infrastructure and fixes the following specific cases: REINDEX INDEX, REINDEX TABLE, LOCK TABLE, and and DROP TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE. Per discussion with Noah Misch and Alvaro Herrera.
2011-11-30 16:12:27 +01:00
/*
* Before acquiring a table lock, check whether we have sufficient rights.
* In the case of DROP INDEX, also try to lock the table before the index.
*/
static void
RangeVarCallbackForDropRelation(const RangeVar *rel, Oid relOid, Oid oldRelOid,
void *arg)
{
HeapTuple tuple;
struct DropRelationCallbackState *state;
char relkind;
Form_pg_class classform;
Add DROP INDEX CONCURRENTLY [IF EXISTS], uses ShareUpdateExclusiveLock
2012-04-06 11:21:40 +02:00
LOCKMODE heap_lockmode;
Improve table locking behavior in the face of current DDL. In the previous coding, callers were faced with an awkward choice: look up the name, do permissions checks, and then lock the table; or look up the name, lock the table, and then do permissions checks. The first choice was wrong because the results of the name lookup and permissions checks might be out-of-date by the time the table lock was acquired, while the second allowed a user with no privileges to interfere with access to a table by users who do have privileges (e.g. if a malicious backend queues up for an AccessExclusiveLock on a table on which AccessShareLock is already held, further attempts to access the table will be blocked until the AccessExclusiveLock is obtained and the malicious backend's transaction rolls back). To fix, allow callers of RangeVarGetRelid() to pass a callback which gets executed after performing the name lookup but before acquiring the relation lock. If the name lookup is retried (because invalidation messages are received), the callback will be re-executed as well, so we get the best of both worlds. RangeVarGetRelid() is renamed to RangeVarGetRelidExtended(); callers not wishing to supply a callback can continue to invoke it as RangeVarGetRelid(), which is now a macro. Since the only one caller that uses nowait = true now passes a callback anyway, the RangeVarGetRelid() macro defaults nowait as well. The callback can also be used for supplemental locking - for example, REINDEX INDEX needs to acquire the table lock before the index lock to reduce deadlock possibilities. There's a lot more work to be done here to fix all the cases where this can be a problem, but this commit provides the general infrastructure and fixes the following specific cases: REINDEX INDEX, REINDEX TABLE, LOCK TABLE, and and DROP TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE. Per discussion with Noah Misch and Alvaro Herrera.
2011-11-30 16:12:27 +01:00
state = (struct DropRelationCallbackState *) arg;
relkind = state->relkind;
Add DROP INDEX CONCURRENTLY [IF EXISTS], uses ShareUpdateExclusiveLock
2012-04-06 11:21:40 +02:00
heap_lockmode = state->concurrent ?
ShareUpdateExclusiveLock : AccessExclusiveLock;
Improve table locking behavior in the face of current DDL. In the previous coding, callers were faced with an awkward choice: look up the name, do permissions checks, and then lock the table; or look up the name, lock the table, and then do permissions checks. The first choice was wrong because the results of the name lookup and permissions checks might be out-of-date by the time the table lock was acquired, while the second allowed a user with no privileges to interfere with access to a table by users who do have privileges (e.g. if a malicious backend queues up for an AccessExclusiveLock on a table on which AccessShareLock is already held, further attempts to access the table will be blocked until the AccessExclusiveLock is obtained and the malicious backend's transaction rolls back). To fix, allow callers of RangeVarGetRelid() to pass a callback which gets executed after performing the name lookup but before acquiring the relation lock. If the name lookup is retried (because invalidation messages are received), the callback will be re-executed as well, so we get the best of both worlds. RangeVarGetRelid() is renamed to RangeVarGetRelidExtended(); callers not wishing to supply a callback can continue to invoke it as RangeVarGetRelid(), which is now a macro. Since the only one caller that uses nowait = true now passes a callback anyway, the RangeVarGetRelid() macro defaults nowait as well. The callback can also be used for supplemental locking - for example, REINDEX INDEX needs to acquire the table lock before the index lock to reduce deadlock possibilities. There's a lot more work to be done here to fix all the cases where this can be a problem, but this commit provides the general infrastructure and fixes the following specific cases: REINDEX INDEX, REINDEX TABLE, LOCK TABLE, and and DROP TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE. Per discussion with Noah Misch and Alvaro Herrera.
2011-11-30 16:12:27 +01:00
/*
* If we previously locked some other index's heap, and the name we're
* looking up no longer refers to that relation, release the now-useless
* lock.
*/
if (relOid != oldRelOid && OidIsValid(state->heapOid))
{
Add DROP INDEX CONCURRENTLY [IF EXISTS], uses ShareUpdateExclusiveLock
2012-04-06 11:21:40 +02:00
UnlockRelationOid(state->heapOid, heap_lockmode);
Improve table locking behavior in the face of current DDL. In the previous coding, callers were faced with an awkward choice: look up the name, do permissions checks, and then lock the table; or look up the name, lock the table, and then do permissions checks. The first choice was wrong because the results of the name lookup and permissions checks might be out-of-date by the time the table lock was acquired, while the second allowed a user with no privileges to interfere with access to a table by users who do have privileges (e.g. if a malicious backend queues up for an AccessExclusiveLock on a table on which AccessShareLock is already held, further attempts to access the table will be blocked until the AccessExclusiveLock is obtained and the malicious backend's transaction rolls back). To fix, allow callers of RangeVarGetRelid() to pass a callback which gets executed after performing the name lookup but before acquiring the relation lock. If the name lookup is retried (because invalidation messages are received), the callback will be re-executed as well, so we get the best of both worlds. RangeVarGetRelid() is renamed to RangeVarGetRelidExtended(); callers not wishing to supply a callback can continue to invoke it as RangeVarGetRelid(), which is now a macro. Since the only one caller that uses nowait = true now passes a callback anyway, the RangeVarGetRelid() macro defaults nowait as well. The callback can also be used for supplemental locking - for example, REINDEX INDEX needs to acquire the table lock before the index lock to reduce deadlock possibilities. There's a lot more work to be done here to fix all the cases where this can be a problem, but this commit provides the general infrastructure and fixes the following specific cases: REINDEX INDEX, REINDEX TABLE, LOCK TABLE, and and DROP TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE. Per discussion with Noah Misch and Alvaro Herrera.
2011-11-30 16:12:27 +01:00
state->heapOid = InvalidOid;
}
Typo fixes for commit 2ad36c4e44c8b513f6155656e1b7a8d26715bb94. Noted during post-commit review by by Noah Misch.
2011-12-06 21:50:02 +01:00
/* Didn't find a relation, so no need for locking or permission checks. */
Improve table locking behavior in the face of current DDL. In the previous coding, callers were faced with an awkward choice: look up the name, do permissions checks, and then lock the table; or look up the name, lock the table, and then do permissions checks. The first choice was wrong because the results of the name lookup and permissions checks might be out-of-date by the time the table lock was acquired, while the second allowed a user with no privileges to interfere with access to a table by users who do have privileges (e.g. if a malicious backend queues up for an AccessExclusiveLock on a table on which AccessShareLock is already held, further attempts to access the table will be blocked until the AccessExclusiveLock is obtained and the malicious backend's transaction rolls back). To fix, allow callers of RangeVarGetRelid() to pass a callback which gets executed after performing the name lookup but before acquiring the relation lock. If the name lookup is retried (because invalidation messages are received), the callback will be re-executed as well, so we get the best of both worlds. RangeVarGetRelid() is renamed to RangeVarGetRelidExtended(); callers not wishing to supply a callback can continue to invoke it as RangeVarGetRelid(), which is now a macro. Since the only one caller that uses nowait = true now passes a callback anyway, the RangeVarGetRelid() macro defaults nowait as well. The callback can also be used for supplemental locking - for example, REINDEX INDEX needs to acquire the table lock before the index lock to reduce deadlock possibilities. There's a lot more work to be done here to fix all the cases where this can be a problem, but this commit provides the general infrastructure and fixes the following specific cases: REINDEX INDEX, REINDEX TABLE, LOCK TABLE, and and DROP TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE. Per discussion with Noah Misch and Alvaro Herrera.
2011-11-30 16:12:27 +01:00
if (!OidIsValid(relOid))
return;
tuple = SearchSysCache1(RELOID, ObjectIdGetDatum(relOid));
if (!HeapTupleIsValid(tuple))
return; /* concurrently dropped, so nothing to do */
classform = (Form_pg_class) GETSTRUCT(tuple);
if (classform->relkind != relkind)
DropErrorMsgWrongType(rel->relname, classform->relkind, relkind);
/* Allow DROP to either table owner or schema owner */
if (!pg_class_ownercheck(relOid, GetUserId()) &&
!pg_namespace_ownercheck(classform->relnamespace, GetUserId()))
aclcheck_error(ACLCHECK_NOT_OWNER, ACL_KIND_CLASS,
rel->relname);
if (!allowSystemTableMods && IsSystemClass(classform))
ereport(ERROR,
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
errmsg("permission denied: \"%s\" is a system catalog",
rel->relname)));
ReleaseSysCache(tuple);
/*
* In DROP INDEX, attempt to acquire lock on the parent table before
* locking the index. index_drop() will need this anyway, and since
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* regular queries lock tables before their indexes, we risk deadlock if
* we do it the other way around. No error if we don't find a pg_index
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY. Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor choice of catalog state representation. The pg_index state for an index that's reached the final pre-drop stage was the same as the state for an index just created by CREATE INDEX CONCURRENTLY. This meant that the (necessary) change to make RelationGetIndexList ignore about-to-die indexes also made it ignore freshly-created indexes; which is catastrophic because the latter do need to be considered in HOT-safety decisions. Failure to do so leads to incorrect index entries and subsequently wrong results from queries depending on the concurrently-created index. To fix, add an additional boolean column "indislive" to pg_index, so that the freshly-created and about-to-die states can be distinguished. (This change obviously is only possible in HEAD. This patch will need to be back-patched, but in 9.2 we'll use a kluge consisting of overloading the formerly-impossible state of indisvalid = true and indisready = false.) In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index flag changes they make without exclusive lock on the index are made via heap_inplace_update() rather than a normal transactional update. The latter is not very safe because moving the pg_index tuple could result in concurrent SnapshotNow scans finding it twice or not at all, thus possibly resulting in index corruption. This is a pre-existing bug in CREATE INDEX CONCURRENTLY, which was copied into the DROP code. In addition, fix various places in the code that ought to check to make sure that the indexes they are manipulating are valid and/or ready as appropriate. These represent bugs that have existed since 8.2, since a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid index behind, and we ought not try to do anything that might fail with such an index. Also fix RelationReloadIndexInfo to ensure it copies all the pg_index columns that are allowed to change after initial creation. Previously we could have been left with stale values of some fields in an index relcache entry. It's not clear whether this actually had any user-visible consequences, but it's at least a bug waiting to happen. In addition, do some code and docs review for DROP INDEX CONCURRENTLY; some cosmetic code cleanup but mostly addition and revision of comments. This will need to be back-patched, but in a noticeably different form, so I'm committing it to HEAD before working on the back-patch. Problem reported by Amit Kapila, diagnosis by Pavan Deolassee, fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
* entry, though --- the relation may have been dropped.
Improve table locking behavior in the face of current DDL. In the previous coding, callers were faced with an awkward choice: look up the name, do permissions checks, and then lock the table; or look up the name, lock the table, and then do permissions checks. The first choice was wrong because the results of the name lookup and permissions checks might be out-of-date by the time the table lock was acquired, while the second allowed a user with no privileges to interfere with access to a table by users who do have privileges (e.g. if a malicious backend queues up for an AccessExclusiveLock on a table on which AccessShareLock is already held, further attempts to access the table will be blocked until the AccessExclusiveLock is obtained and the malicious backend's transaction rolls back). To fix, allow callers of RangeVarGetRelid() to pass a callback which gets executed after performing the name lookup but before acquiring the relation lock. If the name lookup is retried (because invalidation messages are received), the callback will be re-executed as well, so we get the best of both worlds. RangeVarGetRelid() is renamed to RangeVarGetRelidExtended(); callers not wishing to supply a callback can continue to invoke it as RangeVarGetRelid(), which is now a macro. Since the only one caller that uses nowait = true now passes a callback anyway, the RangeVarGetRelid() macro defaults nowait as well. The callback can also be used for supplemental locking - for example, REINDEX INDEX needs to acquire the table lock before the index lock to reduce deadlock possibilities. There's a lot more work to be done here to fix all the cases where this can be a problem, but this commit provides the general infrastructure and fixes the following specific cases: REINDEX INDEX, REINDEX TABLE, LOCK TABLE, and and DROP TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE. Per discussion with Noah Misch and Alvaro Herrera.
2011-11-30 16:12:27 +01:00
*/
if (relkind == RELKIND_INDEX && relOid != oldRelOid)
{
state->heapOid = IndexGetRelation(relOid, true);
if (OidIsValid(state->heapOid))
Add DROP INDEX CONCURRENTLY [IF EXISTS], uses ShareUpdateExclusiveLock
2012-04-06 11:21:40 +02:00
LockRelationOid(state->heapOid, heap_lockmode);
Improve table locking behavior in the face of current DDL. In the previous coding, callers were faced with an awkward choice: look up the name, do permissions checks, and then lock the table; or look up the name, lock the table, and then do permissions checks. The first choice was wrong because the results of the name lookup and permissions checks might be out-of-date by the time the table lock was acquired, while the second allowed a user with no privileges to interfere with access to a table by users who do have privileges (e.g. if a malicious backend queues up for an AccessExclusiveLock on a table on which AccessShareLock is already held, further attempts to access the table will be blocked until the AccessExclusiveLock is obtained and the malicious backend's transaction rolls back). To fix, allow callers of RangeVarGetRelid() to pass a callback which gets executed after performing the name lookup but before acquiring the relation lock. If the name lookup is retried (because invalidation messages are received), the callback will be re-executed as well, so we get the best of both worlds. RangeVarGetRelid() is renamed to RangeVarGetRelidExtended(); callers not wishing to supply a callback can continue to invoke it as RangeVarGetRelid(), which is now a macro. Since the only one caller that uses nowait = true now passes a callback anyway, the RangeVarGetRelid() macro defaults nowait as well. The callback can also be used for supplemental locking - for example, REINDEX INDEX needs to acquire the table lock before the index lock to reduce deadlock possibilities. There's a lot more work to be done here to fix all the cases where this can be a problem, but this commit provides the general infrastructure and fixes the following specific cases: REINDEX INDEX, REINDEX TABLE, LOCK TABLE, and and DROP TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE. Per discussion with Noah Misch and Alvaro Herrera.
2011-11-30 16:12:27 +01:00
}
}
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
/*
Generalize TRUNCATE to support truncating multiple tables in one command. This is useful because we can allow truncation of tables referenced by foreign keys, so long as the referencing table is truncated in the same command. Alvaro Herrera
2005-01-27 04:19:37 +01:00
* ExecuteTruncate
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Executes a TRUNCATE command.
Generalize TRUNCATE to support truncating multiple tables in one command. This is useful because we can allow truncation of tables referenced by foreign keys, so long as the referencing table is truncated in the same command. Alvaro Herrera
2005-01-27 04:19:37 +01:00
*
Add CASCADE option to TRUNCATE. Joachim Wieland
2006-03-03 04:30:54 +01:00
* This is a multi-relation truncate. We first open and grab exclusive
* lock on all relations involved, checking permissions and otherwise
* verifying that the relation is OK for truncation. In CASCADE mode,
* relations having FK references to the targeted relations are automatically
* added to the group; in RESTRICT mode, we check that all FK references are
* internal to the group that's being truncated. Finally all the relations
* are truncated and reindexed.
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
*/
void
Add CASCADE option to TRUNCATE. Joachim Wieland
2006-03-03 04:30:54 +01:00
ExecuteTruncate(TruncateStmt *stmt)
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
{
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
List *rels = NIL;
Dept. of second thoughts: rejigger the TRUNCATE ... CASCADE patch so that 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.
2006-03-03 19:25:14 +01:00
List *relids = NIL;
Add a RESTART (without parameter) option to ALTER SEQUENCE, allowing a sequence to be reset to its original starting value. This requires adding the original start value to the set of parameters (columns) of a sequence object, which is a user-visible change with potential compatibility implications; it also forces initdb. Also add hopefully-SQL-compatible RESTART/CONTINUE IDENTITY options to TRUNCATE TABLE. RESTART IDENTITY executes ALTER SEQUENCE RESTART for all sequences "owned by" any of the truncated relations. CONTINUE IDENTITY is a no-op option. Zoltan Boszormenyi
2008-05-17 01:36:05 +02:00
List *seq_relids = NIL;
Support statement-level ON TRUNCATE triggers. Simon Riggs
2008-03-28 01:21:56 +01:00
EState *estate;
ResultRelInfo *resultRelInfos;
ResultRelInfo *resultRelInfo;
Make TRUNCATE do truncate-in-place when processing a relation that was created or previously truncated in the current (sub)transaction. This is safe since if the (sub)transaction later rolls back, we'd just discard the rel's current physical file anyway. This avoids unreasonable growth in the number of transient files when a relation is repeatedly truncated. Per a performance gripe a couple weeks ago from Todd Cook.
2009-08-23 21:23:41 +02:00
SubTransactionId mySubid;
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
ListCell *cell;
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
Add CASCADE option to TRUNCATE. Joachim Wieland
2006-03-03 04:30:54 +01:00
/*
Dept. of second thoughts: rejigger the TRUNCATE ... CASCADE patch so that 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.
2006-03-03 19:25:14 +01:00
* Open, exclusive-lock, and check all the explicitly-specified relations
Add CASCADE option to TRUNCATE. Joachim Wieland
2006-03-03 04:30:54 +01:00
*/
foreach(cell, stmt->relations)
Generalize TRUNCATE to support truncating multiple tables in one command. This is useful because we can allow truncation of tables referenced by foreign keys, so long as the referencing table is truncated in the same command. Alvaro Herrera
2005-01-27 04:19:37 +01:00
{
RangeVar *rv = lfirst(cell);
Dept. of second thoughts: rejigger the TRUNCATE ... CASCADE patch so that 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.
2006-03-03 19:25:14 +01:00
Relation rel;
Add ONLY support to LOCK and TRUNCATE. By default, these commands are now recursive. => Note this incompatibility in the release notes.
2009-01-12 09:54:27 +01:00
bool recurse = interpretInhOption(rv->inhOpt);
Oid myrelid;
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
Generalize TRUNCATE to support truncating multiple tables in one command. This is useful because we can allow truncation of tables referenced by foreign keys, so long as the referencing table is truncated in the same command. Alvaro Herrera
2005-01-27 04:19:37 +01:00
rel = heap_openrv(rv, AccessExclusiveLock);
Add ONLY support to LOCK and TRUNCATE. By default, these commands are now recursive. => Note this incompatibility in the release notes.
2009-01-12 09:54:27 +01:00
myrelid = RelationGetRelid(rel);
Fix previous patch so that it actually works --- consider TRUNCATE foo, public.foo
2008-07-16 21:33:25 +02:00
/* don't throw error for "TRUNCATE foo, foo" */
Add ONLY support to LOCK and TRUNCATE. By default, these commands are now recursive. => Note this incompatibility in the release notes.
2009-01-12 09:54:27 +01:00
if (list_member_oid(relids, myrelid))
Fix previous patch so that it actually works --- consider TRUNCATE foo, public.foo
2008-07-16 21:33:25 +02:00
{
heap_close(rel, AccessExclusiveLock);
continue;
}
Dept. of second thoughts: rejigger the TRUNCATE ... CASCADE patch so that 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.
2006-03-03 19:25:14 +01:00
truncate_check_rel(rel);
Add CASCADE option to TRUNCATE. Joachim Wieland
2006-03-03 04:30:54 +01:00
rels = lappend(rels, rel);
Add ONLY support to LOCK and TRUNCATE. By default, these commands are now recursive. => Note this incompatibility in the release notes.
2009-01-12 09:54:27 +01:00
relids = lappend_oid(relids, myrelid);
if (recurse)
{
ListCell *child;
List *children;
Tighten integrity checks on ALTER TABLE ... ALTER COLUMN ... RENAME. When a column is renamed, we recursively rename the same column in all descendent tables. But if one of those tables also inherits that column from a table outside the inheritance hierarchy rooted at the named table, we must throw an error. The previous coding correctly prohibited the rename when the parent had inherited the column from elsewhere, but overlooked the case where the parent was OK but a child table also inherited the same column from a second, unrelated parent. For now, not backpatched due to lack of complaints from the field. KaiGai Kohei, with further changes by me. Reviewed by Bernd Helme and Tom Lane.
2010-02-01 20:28:56 +01:00
children = find_all_inheritors(myrelid, AccessExclusiveLock, NULL);
Add ONLY support to LOCK and TRUNCATE. By default, these commands are now recursive. => Note this incompatibility in the release notes.
2009-01-12 09:54:27 +01:00
foreach(child, children)
{
Oid childrelid = lfirst_oid(child);
if (list_member_oid(relids, childrelid))
continue;
Modify find_inheritance_children() and find_all_inheritors() to add the ability to lock relations as they scan pg_inherits, and to ignore any relations that have disappeared by the time we get lock on them. This makes uses of these functions safe against concurrent DROP operations on child tables: we will effectively ignore any just-dropped child, rather than possibly throwing an error as in recent bug report from Thomas Johansson (and similar past complaints). The behavior should not change otherwise, since the code was acquiring those same locks anyway, just a little bit later. An exception is LockTableCommand(), which is still behaving unsafely; but that seems to require some more discussion before we change it.
2009-05-12 05:11:02 +02:00
/* find_all_inheritors already got lock */
rel = heap_open(childrelid, NoLock);
Add ONLY support to LOCK and TRUNCATE. By default, these commands are now recursive. => Note this incompatibility in the release notes.
2009-01-12 09:54:27 +01:00
truncate_check_rel(rel);
rels = lappend(rels, rel);
relids = lappend_oid(relids, childrelid);
}
}
Add CASCADE option to TRUNCATE. Joachim Wieland
2006-03-03 04:30:54 +01:00
}
/*
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* In CASCADE mode, suck in all referencing relations as well. This
* requires multiple iterations to find indirectly-dependent relations. At
* each phase, we need to exclusive-lock new rels before looking for their
* dependencies, else we might miss something. Also, we check each rel as
* soon as we open it, to avoid a faux pas such as holding lock for a long
* time on a rel we have no permissions for.
Add CASCADE option to TRUNCATE. Joachim Wieland
2006-03-03 04:30:54 +01:00
*/
if (stmt->behavior == DROP_CASCADE)
{
for (;;)
{
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
List *newrelids;
Add CASCADE option to TRUNCATE. Joachim Wieland
2006-03-03 04:30:54 +01:00
newrelids = heap_truncate_find_FKs(relids);
if (newrelids == NIL)
break; /* nothing else to add */
foreach(cell, newrelids)
{
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
Oid relid = lfirst_oid(cell);
Dept. of second thoughts: rejigger the TRUNCATE ... CASCADE patch so that 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.
2006-03-03 19:25:14 +01:00
Relation rel;
Add CASCADE option to TRUNCATE. Joachim Wieland
2006-03-03 04:30:54 +01:00
rel = heap_open(relid, AccessExclusiveLock);
Dept. of second thoughts: rejigger the TRUNCATE ... CASCADE patch so that 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.
2006-03-03 19:25:14 +01:00
ereport(NOTICE,
(errmsg("truncate cascades to table \"%s\"",
RelationGetRelationName(rel))));
truncate_check_rel(rel);
Add CASCADE option to TRUNCATE. Joachim Wieland
2006-03-03 04:30:54 +01:00
rels = lappend(rels, rel);
relids = lappend_oid(relids, relid);
}
}
}
Transaction safe Truncate Rod Taylor
2002-11-23 05:05:52 +01:00
/*
Add CASCADE option to TRUNCATE. Joachim Wieland
2006-03-03 04:30:54 +01:00
* Check foreign key references. In CASCADE mode, this should be
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* unnecessary since we just pulled in all the references; but as a
* cross-check, do it anyway if in an Assert-enabled build.
Transaction safe Truncate Rod Taylor
2002-11-23 05:05:52 +01:00
*/
Add CASCADE option to TRUNCATE. Joachim Wieland
2006-03-03 04:30:54 +01:00
#ifdef USE_ASSERT_CHECKING
Generalize TRUNCATE to support truncating multiple tables in one command. This is useful because we can allow truncation of tables referenced by foreign keys, so long as the referencing table is truncated in the same command. Alvaro Herrera
2005-01-27 04:19:37 +01:00
heap_truncate_check_FKs(rels, false);
Add CASCADE option to TRUNCATE. Joachim Wieland
2006-03-03 04:30:54 +01:00
#else
if (stmt->behavior == DROP_RESTRICT)
heap_truncate_check_FKs(rels, false);
#endif
Code review for transaction-safe-TRUNCATE patch: minor cleanups.
2002-12-30 20:45:17 +01:00
Add a RESTART (without parameter) option to ALTER SEQUENCE, allowing a sequence to be reset to its original starting value. This requires adding the original start value to the set of parameters (columns) of a sequence object, which is a user-visible change with potential compatibility implications; it also forces initdb. Also add hopefully-SQL-compatible RESTART/CONTINUE IDENTITY options to TRUNCATE TABLE. RESTART IDENTITY executes ALTER SEQUENCE RESTART for all sequences "owned by" any of the truncated relations. CONTINUE IDENTITY is a no-op option. Zoltan Boszormenyi
2008-05-17 01:36:05 +02:00
/*
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* If we are asked to restart sequences, find all the sequences, lock them
Make TRUNCATE ... RESTART IDENTITY restart sequences transactionally. In the previous coding, we simply issued ALTER SEQUENCE RESTART commands, which do not roll back on error. This meant that an error between truncating and committing left the sequences out of sync with the table contents, with potentially bad consequences as were noted in a Warning on the TRUNCATE man page. To fix, create a new storage file (relfilenode) for a sequence that is to be reset due to RESTART IDENTITY. If the transaction aborts, we'll automatically revert to the old storage file. This acts just like a rewriting ALTER TABLE operation. A penalty is that we have to take exclusive lock on the sequence, but since we've already got exclusive lock on its owning table, that seems unlikely to be much of a problem. The interaction of this with usual nontransactional behaviors of sequence operations is a bit weird, but it's hard to see what would be completely consistent. Our choice is to discard cached-but-unissued sequence values both when the RESTART is executed, and at rollback if any; but to not touch the currval() state either time. In passing, move the sequence reset operations to happen before not after any AFTER TRUNCATE triggers are fired. The previous ordering was not logically sensible, but was forced by the need to minimize inconsistency if the triggers caused an error. Transactional rollback is a much better solution to that. Patch by Steve Singer, rather heavily adjusted by me.
2010-11-17 22:42:18 +01:00
* (we need AccessExclusiveLock for ResetSequence), and check permissions.
* We want to do this early since it's pointless to do all the truncation
* work only to fail on sequence permissions.
Add a RESTART (without parameter) option to ALTER SEQUENCE, allowing a sequence to be reset to its original starting value. This requires adding the original start value to the set of parameters (columns) of a sequence object, which is a user-visible change with potential compatibility implications; it also forces initdb. Also add hopefully-SQL-compatible RESTART/CONTINUE IDENTITY options to TRUNCATE TABLE. RESTART IDENTITY executes ALTER SEQUENCE RESTART for all sequences "owned by" any of the truncated relations. CONTINUE IDENTITY is a no-op option. Zoltan Boszormenyi
2008-05-17 01:36:05 +02:00
*/
if (stmt->restart_seqs)
{
foreach(cell, rels)
{
Relation rel = (Relation) lfirst(cell);
List *seqlist = getOwnedSequences(RelationGetRelid(rel));
ListCell *seqcell;
foreach(seqcell, seqlist)
{
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
Oid seq_relid = lfirst_oid(seqcell);
Relation seq_rel;
Add a RESTART (without parameter) option to ALTER SEQUENCE, allowing a sequence to be reset to its original starting value. This requires adding the original start value to the set of parameters (columns) of a sequence object, which is a user-visible change with potential compatibility implications; it also forces initdb. Also add hopefully-SQL-compatible RESTART/CONTINUE IDENTITY options to TRUNCATE TABLE. RESTART IDENTITY executes ALTER SEQUENCE RESTART for all sequences "owned by" any of the truncated relations. CONTINUE IDENTITY is a no-op option. Zoltan Boszormenyi
2008-05-17 01:36:05 +02:00
Make TRUNCATE ... RESTART IDENTITY restart sequences transactionally. In the previous coding, we simply issued ALTER SEQUENCE RESTART commands, which do not roll back on error. This meant that an error between truncating and committing left the sequences out of sync with the table contents, with potentially bad consequences as were noted in a Warning on the TRUNCATE man page. To fix, create a new storage file (relfilenode) for a sequence that is to be reset due to RESTART IDENTITY. If the transaction aborts, we'll automatically revert to the old storage file. This acts just like a rewriting ALTER TABLE operation. A penalty is that we have to take exclusive lock on the sequence, but since we've already got exclusive lock on its owning table, that seems unlikely to be much of a problem. The interaction of this with usual nontransactional behaviors of sequence operations is a bit weird, but it's hard to see what would be completely consistent. Our choice is to discard cached-but-unissued sequence values both when the RESTART is executed, and at rollback if any; but to not touch the currval() state either time. In passing, move the sequence reset operations to happen before not after any AFTER TRUNCATE triggers are fired. The previous ordering was not logically sensible, but was forced by the need to minimize inconsistency if the triggers caused an error. Transactional rollback is a much better solution to that. Patch by Steve Singer, rather heavily adjusted by me.
2010-11-17 22:42:18 +01:00
seq_rel = relation_open(seq_relid, AccessExclusiveLock);
Add a RESTART (without parameter) option to ALTER SEQUENCE, allowing a sequence to be reset to its original starting value. This requires adding the original start value to the set of parameters (columns) of a sequence object, which is a user-visible change with potential compatibility implications; it also forces initdb. Also add hopefully-SQL-compatible RESTART/CONTINUE IDENTITY options to TRUNCATE TABLE. RESTART IDENTITY executes ALTER SEQUENCE RESTART for all sequences "owned by" any of the truncated relations. CONTINUE IDENTITY is a no-op option. Zoltan Boszormenyi
2008-05-17 01:36:05 +02:00
/* This check must match AlterSequence! */
if (!pg_class_ownercheck(seq_relid, GetUserId()))
aclcheck_error(ACLCHECK_NOT_OWNER, ACL_KIND_CLASS,
RelationGetRelationName(seq_rel));
seq_relids = lappend_oid(seq_relids, seq_relid);
relation_close(seq_rel, NoLock);
}
}
}
Support statement-level ON TRUNCATE triggers. Simon Riggs
2008-03-28 01:21:56 +01:00
/* Prepare to catch AFTER triggers. */
AfterTriggerBeginQuery();
/*
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* To fire triggers, we'll need an EState as well as a ResultRelInfo for
Support data-modifying commands (INSERT/UPDATE/DELETE) in WITH. 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
2011-02-26 00:56:23 +01:00
* each relation. We don't need to call ExecOpenIndices, though.
Support statement-level ON TRUNCATE triggers. Simon Riggs
2008-03-28 01:21:56 +01:00
*/
estate = CreateExecutorState();
resultRelInfos = (ResultRelInfo *)
palloc(list_length(rels) * sizeof(ResultRelInfo));
resultRelInfo = resultRelInfos;
foreach(cell, rels)
{
Relation rel = (Relation) lfirst(cell);
InitResultRelInfo(resultRelInfo,
rel,
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
0, /* dummy rangetable index */
Add an EXPLAIN (BUFFERS) option to show buffer-usage statistics. This patch also removes buffer-usage statistics from the track_counts output, since this (or the global server statistics) is deemed to be a better interface to this information. Itagaki Takahiro, reviewed by Euler Taveira de Oliveira.
2009-12-15 05:57:48 +01:00
0);
Support statement-level ON TRUNCATE triggers. Simon Riggs
2008-03-28 01:21:56 +01:00
resultRelInfo++;
}
estate->es_result_relations = resultRelInfos;
estate->es_num_result_relations = list_length(rels);
/*
* Process all BEFORE STATEMENT TRUNCATE triggers before we begin
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* truncating (this is because one of them might throw an error). Also, if
* we were to allow them to prevent statement execution, that would need
* to be handled here.
Support statement-level ON TRUNCATE triggers. Simon Riggs
2008-03-28 01:21:56 +01:00
*/
resultRelInfo = resultRelInfos;
foreach(cell, rels)
{
estate->es_result_relation_info = resultRelInfo;
ExecBSTruncateTriggers(estate, resultRelInfo);
resultRelInfo++;
}
Code review for transaction-safe-TRUNCATE patch: minor cleanups.
2002-12-30 20:45:17 +01:00
/*
Generalize TRUNCATE to support truncating multiple tables in one command. This is useful because we can allow truncation of tables referenced by foreign keys, so long as the referencing table is truncated in the same command. Alvaro Herrera
2005-01-27 04:19:37 +01:00
* OK, truncate each table.
Code review for transaction-safe-TRUNCATE patch: minor cleanups.
2002-12-30 20:45:17 +01:00
*/
Make TRUNCATE do truncate-in-place when processing a relation that was created or previously truncated in the current (sub)transaction. This is safe since if the (sub)transaction later rolls back, we'd just discard the rel's current physical file anyway. This avoids unreasonable growth in the number of transient files when a relation is repeatedly truncated. Per a performance gripe a couple weeks ago from Todd Cook.
2009-08-23 21:23:41 +02:00
mySubid = GetCurrentSubTransactionId();
Generalize TRUNCATE to support truncating multiple tables in one command. This is useful because we can allow truncation of tables referenced by foreign keys, so long as the referencing table is truncated in the same command. Alvaro Herrera
2005-01-27 04:19:37 +01:00
foreach(cell, rels)
Get rid of cluster.c's apparatus for rebuilding a relation's indexes in favor of using the REINDEX TABLE apparatus, which does the same thing simpler and faster. Also, make TRUNCATE not use cluster.c at all, but just assign a new relfilenode and REINDEX. This partially addresses Hartmut Raschick's complaint from last December that 7.4's TRUNCATE is an order of magnitude slower than prior releases. By getting rid of a lot of unnecessary catalog updates, these changes buy back about a factor of two (on my system). The remaining overhead seems associated with creating and deleting storage files, which we may not be able to do much about without abandoning transaction safety for TRUNCATE.
2004-05-08 02:34:49 +02:00
{
Dept. of second thoughts: rejigger the TRUNCATE ... CASCADE patch so that 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.
2006-03-03 19:25:14 +01:00
Relation rel = (Relation) lfirst(cell);
Generalize TRUNCATE to support truncating multiple tables in one command. This is useful because we can allow truncation of tables referenced by foreign keys, so long as the referencing table is truncated in the same command. Alvaro Herrera
2005-01-27 04:19:37 +01:00
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* Normally, we need a transaction-safe truncation here. However, if
* the table was either created in the current (sub)transaction or has
* a new relfilenode in the current (sub)transaction, then we can just
* truncate it in-place, because a rollback would cause the whole
* table or the current physical file to be thrown away anyway.
Generalize TRUNCATE to support truncating multiple tables in one command. This is useful because we can allow truncation of tables referenced by foreign keys, so long as the referencing table is truncated in the same command. Alvaro Herrera
2005-01-27 04:19:37 +01:00
*/
Make TRUNCATE do truncate-in-place when processing a relation that was created or previously truncated in the current (sub)transaction. This is safe since if the (sub)transaction later rolls back, we'd just discard the rel's current physical file anyway. This avoids unreasonable growth in the number of transient files when a relation is repeatedly truncated. Per a performance gripe a couple weeks ago from Todd Cook.
2009-08-23 21:23:41 +02:00
if (rel->rd_createSubid == mySubid ||
rel->rd_newRelfilenodeSubid == mySubid)
Generalize TRUNCATE to support truncating multiple tables in one command. This is useful because we can allow truncation of tables referenced by foreign keys, so long as the referencing table is truncated in the same command. Alvaro Herrera
2005-01-27 04:19:37 +01:00
{
Make TRUNCATE do truncate-in-place when processing a relation that was created or previously truncated in the current (sub)transaction. This is safe since if the (sub)transaction later rolls back, we'd just discard the rel's current physical file anyway. This avoids unreasonable growth in the number of transient files when a relation is repeatedly truncated. Per a performance gripe a couple weeks ago from Todd Cook.
2009-08-23 21:23:41 +02:00
/* Immediate, non-rollbackable truncation is OK */
heap_truncate_one_rel(rel);
Generalize TRUNCATE to support truncating multiple tables in one command. This is useful because we can allow truncation of tables referenced by foreign keys, so long as the referencing table is truncated in the same command. Alvaro Herrera
2005-01-27 04:19:37 +01:00
}
Make TRUNCATE do truncate-in-place when processing a relation that was created or previously truncated in the current (sub)transaction. This is safe since if the (sub)transaction later rolls back, we'd just discard the rel's current physical file anyway. This avoids unreasonable growth in the number of transient files when a relation is repeatedly truncated. Per a performance gripe a couple weeks ago from Todd Cook.
2009-08-23 21:23:41 +02:00
else
{
Oid heap_relid;
Oid toast_relid;
pgindent run for release 9.3 This is the first run of the Perl-based pgindent script. Also update pgindent instructions.
2013-05-29 22:58:43 +02:00
MultiXactId minmulti;
Make TRUNCATE do truncate-in-place when processing a relation that was created or previously truncated in the current (sub)transaction. This is safe since if the (sub)transaction later rolls back, we'd just discard the rel's current physical file anyway. This avoids unreasonable growth in the number of transient files when a relation is repeatedly truncated. Per a performance gripe a couple weeks ago from Todd Cook.
2009-08-23 21:23:41 +02:00
Make DDL operations play nicely with Serializable Snapshot Isolation. 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.
2011-06-08 12:47:21 +02:00
/*
* This effectively deletes all rows in the table, and may be done
* in a serializable transaction. In that case we must record a
* rw-conflict in to this transaction from each transaction
* holding a predicate lock on the table.
*/
CheckTableForSerializableConflictIn(rel);
Improve concurrency of foreign key locking This patch introduces two additional lock modes for tuples: "SELECT FOR KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each other, in contrast with already existing "SELECT FOR SHARE" and "SELECT FOR UPDATE". UPDATE commands that do not modify the values stored in the columns that are part of the key of the tuple now grab a SELECT FOR NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently with tuple locks of the FOR KEY SHARE variety. Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this means the concurrency improvement applies to them, which is the whole point of this patch. The added tuple lock semantics require some rejiggering of the multixact module, so that the locking level that each transaction is holding can be stored alongside its Xid. Also, multixacts now need to persist across server restarts and crashes, because they can now represent not only tuple locks, but also tuple updates. This means we need more careful tracking of lifetime of pg_multixact SLRU files; since they now persist longer, we require more infrastructure to figure out when they can be removed. pg_upgrade also needs to be careful to copy pg_multixact files over from the old server to the new, or at least part of multixact.c state, depending on the versions of the old and new servers. Tuple time qualification rules (HeapTupleSatisfies routines) need to be careful not to consider tuples with the "is multi" infomask bit set as being only locked; they might need to look up MultiXact values (i.e. possibly do pg_multixact I/O) to find out the Xid that updated a tuple, whereas they previously were assured to only use information readily available from the tuple header. This is considered acceptable, because the extra I/O would involve cases that would previously cause some commands to block waiting for concurrent transactions to finish. Another important change is the fact that locking tuples that have previously been updated causes the future versions to be marked as locked, too; this is essential for correctness of foreign key checks. This causes additional WAL-logging, also (there was previously a single WAL record for a locked tuple; now there are as many as updated copies of the tuple there exist.) With all this in place, contention related to tuples being checked by foreign key rules should be much reduced. As a bonus, the old behavior that a subtransaction grabbing a stronger tuple lock than the parent (sub)transaction held on a given tuple and later aborting caused the weaker lock to be lost, has been fixed. Many new spec files were added for isolation tester framework, to ensure overall behavior is sane. There's probably room for several more tests. There were several reviewers of this patch; in particular, Noah Misch and Andres Freund spent considerable time in it. Original idea for the patch came from Simon Riggs, after a problem report by Joel Jacobson. Most code is from me, with contributions from Marti Raudsepp, Alexander Shulgin, Noah Misch and Andres Freund. This patch was discussed in several pgsql-hackers threads; the most important start at the following message-ids: AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com 1290721684-sup-3951@alvh.no-ip.org 1294953201-sup-2099@alvh.no-ip.org 1320343602-sup-2290@alvh.no-ip.org 1339690386-sup-8927@alvh.no-ip.org 4FE5FF020200002500048A3D@gw.wicourts.gov 4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
minmulti = GetOldestMultiXactId();
Make TRUNCATE do truncate-in-place when processing a relation that was created or previously truncated in the current (sub)transaction. This is safe since if the (sub)transaction later rolls back, we'd just discard the rel's current physical file anyway. This avoids unreasonable growth in the number of transient files when a relation is repeatedly truncated. Per a performance gripe a couple weeks ago from Todd Cook.
2009-08-23 21:23:41 +02:00
/*
* Need the full transaction-safe pushups.
*
* Create a new empty storage file for the relation, and assign it
* as the relfilenode value. The old storage file is scheduled for
* deletion at commit.
*/
Improve concurrency of foreign key locking This patch introduces two additional lock modes for tuples: "SELECT FOR KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each other, in contrast with already existing "SELECT FOR SHARE" and "SELECT FOR UPDATE". UPDATE commands that do not modify the values stored in the columns that are part of the key of the tuple now grab a SELECT FOR NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently with tuple locks of the FOR KEY SHARE variety. Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this means the concurrency improvement applies to them, which is the whole point of this patch. The added tuple lock semantics require some rejiggering of the multixact module, so that the locking level that each transaction is holding can be stored alongside its Xid. Also, multixacts now need to persist across server restarts and crashes, because they can now represent not only tuple locks, but also tuple updates. This means we need more careful tracking of lifetime of pg_multixact SLRU files; since they now persist longer, we require more infrastructure to figure out when they can be removed. pg_upgrade also needs to be careful to copy pg_multixact files over from the old server to the new, or at least part of multixact.c state, depending on the versions of the old and new servers. Tuple time qualification rules (HeapTupleSatisfies routines) need to be careful not to consider tuples with the "is multi" infomask bit set as being only locked; they might need to look up MultiXact values (i.e. possibly do pg_multixact I/O) to find out the Xid that updated a tuple, whereas they previously were assured to only use information readily available from the tuple header. This is considered acceptable, because the extra I/O would involve cases that would previously cause some commands to block waiting for concurrent transactions to finish. Another important change is the fact that locking tuples that have previously been updated causes the future versions to be marked as locked, too; this is essential for correctness of foreign key checks. This causes additional WAL-logging, also (there was previously a single WAL record for a locked tuple; now there are as many as updated copies of the tuple there exist.) With all this in place, contention related to tuples being checked by foreign key rules should be much reduced. As a bonus, the old behavior that a subtransaction grabbing a stronger tuple lock than the parent (sub)transaction held on a given tuple and later aborting caused the weaker lock to be lost, has been fixed. Many new spec files were added for isolation tester framework, to ensure overall behavior is sane. There's probably room for several more tests. There were several reviewers of this patch; in particular, Noah Misch and Andres Freund spent considerable time in it. Original idea for the patch came from Simon Riggs, after a problem report by Joel Jacobson. Most code is from me, with contributions from Marti Raudsepp, Alexander Shulgin, Noah Misch and Andres Freund. This patch was discussed in several pgsql-hackers threads; the most important start at the following message-ids: AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com 1290721684-sup-3951@alvh.no-ip.org 1294953201-sup-2099@alvh.no-ip.org 1320343602-sup-2290@alvh.no-ip.org 1339690386-sup-8927@alvh.no-ip.org 4FE5FF020200002500048A3D@gw.wicourts.gov 4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
RelationSetNewRelfilenode(rel, RecentXmin, minmulti);
Prevent loss of init fork when truncating an unlogged table. Fixes bug #6635, reported by Akira Kurosawa.
2012-05-11 15:46:42 +02:00
if (rel->rd_rel->relpersistence == RELPERSISTENCE_UNLOGGED)
heap_create_init_fork(rel);
Generalize TRUNCATE to support truncating multiple tables in one command. This is useful because we can allow truncation of tables referenced by foreign keys, so long as the referencing table is truncated in the same command. Alvaro Herrera
2005-01-27 04:19:37 +01:00
Make TRUNCATE do truncate-in-place when processing a relation that was created or previously truncated in the current (sub)transaction. This is safe since if the (sub)transaction later rolls back, we'd just discard the rel's current physical file anyway. This avoids unreasonable growth in the number of transient files when a relation is repeatedly truncated. Per a performance gripe a couple weeks ago from Todd Cook.
2009-08-23 21:23:41 +02:00
heap_relid = RelationGetRelid(rel);
toast_relid = rel->rd_rel->reltoastrelid;
/*
* The same for the toast table, if any.
*/
if (OidIsValid(toast_relid))
{
rel = relation_open(toast_relid, AccessExclusiveLock);
Improve concurrency of foreign key locking This patch introduces two additional lock modes for tuples: "SELECT FOR KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each other, in contrast with already existing "SELECT FOR SHARE" and "SELECT FOR UPDATE". UPDATE commands that do not modify the values stored in the columns that are part of the key of the tuple now grab a SELECT FOR NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently with tuple locks of the FOR KEY SHARE variety. Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this means the concurrency improvement applies to them, which is the whole point of this patch. The added tuple lock semantics require some rejiggering of the multixact module, so that the locking level that each transaction is holding can be stored alongside its Xid. Also, multixacts now need to persist across server restarts and crashes, because they can now represent not only tuple locks, but also tuple updates. This means we need more careful tracking of lifetime of pg_multixact SLRU files; since they now persist longer, we require more infrastructure to figure out when they can be removed. pg_upgrade also needs to be careful to copy pg_multixact files over from the old server to the new, or at least part of multixact.c state, depending on the versions of the old and new servers. Tuple time qualification rules (HeapTupleSatisfies routines) need to be careful not to consider tuples with the "is multi" infomask bit set as being only locked; they might need to look up MultiXact values (i.e. possibly do pg_multixact I/O) to find out the Xid that updated a tuple, whereas they previously were assured to only use information readily available from the tuple header. This is considered acceptable, because the extra I/O would involve cases that would previously cause some commands to block waiting for concurrent transactions to finish. Another important change is the fact that locking tuples that have previously been updated causes the future versions to be marked as locked, too; this is essential for correctness of foreign key checks. This causes additional WAL-logging, also (there was previously a single WAL record for a locked tuple; now there are as many as updated copies of the tuple there exist.) With all this in place, contention related to tuples being checked by foreign key rules should be much reduced. As a bonus, the old behavior that a subtransaction grabbing a stronger tuple lock than the parent (sub)transaction held on a given tuple and later aborting caused the weaker lock to be lost, has been fixed. Many new spec files were added for isolation tester framework, to ensure overall behavior is sane. There's probably room for several more tests. There were several reviewers of this patch; in particular, Noah Misch and Andres Freund spent considerable time in it. Original idea for the patch came from Simon Riggs, after a problem report by Joel Jacobson. Most code is from me, with contributions from Marti Raudsepp, Alexander Shulgin, Noah Misch and Andres Freund. This patch was discussed in several pgsql-hackers threads; the most important start at the following message-ids: AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com 1290721684-sup-3951@alvh.no-ip.org 1294953201-sup-2099@alvh.no-ip.org 1320343602-sup-2290@alvh.no-ip.org 1339690386-sup-8927@alvh.no-ip.org 4FE5FF020200002500048A3D@gw.wicourts.gov 4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
RelationSetNewRelfilenode(rel, RecentXmin, minmulti);
Prevent loss of init fork when truncating an unlogged table. Fixes bug #6635, reported by Akira Kurosawa.
2012-05-11 15:46:42 +02:00
if (rel->rd_rel->relpersistence == RELPERSISTENCE_UNLOGGED)
heap_create_init_fork(rel);
Make TRUNCATE do truncate-in-place when processing a relation that was created or previously truncated in the current (sub)transaction. This is safe since if the (sub)transaction later rolls back, we'd just discard the rel's current physical file anyway. This avoids unreasonable growth in the number of transient files when a relation is repeatedly truncated. Per a performance gripe a couple weeks ago from Todd Cook.
2009-08-23 21:23:41 +02:00
heap_close(rel, NoLock);
}
/*
* Reconstruct the indexes to match, and we're done.
*/
Simplify reindex_relation's API. 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.
2011-04-16 23:26:41 +02:00
reindex_relation(heap_relid, REINDEX_REL_PROCESS_TOAST);
Make TRUNCATE do truncate-in-place when processing a relation that was created or previously truncated in the current (sub)transaction. This is safe since if the (sub)transaction later rolls back, we'd just discard the rel's current physical file anyway. This avoids unreasonable growth in the number of transient files when a relation is repeatedly truncated. Per a performance gripe a couple weeks ago from Todd Cook.
2009-08-23 21:23:41 +02:00
}
Generalize TRUNCATE to support truncating multiple tables in one command. This is useful because we can allow truncation of tables referenced by foreign keys, so long as the referencing table is truncated in the same command. Alvaro Herrera
2005-01-27 04:19:37 +01:00
}
Support statement-level ON TRUNCATE triggers. Simon Riggs
2008-03-28 01:21:56 +01:00
Make TRUNCATE ... RESTART IDENTITY restart sequences transactionally. In the previous coding, we simply issued ALTER SEQUENCE RESTART commands, which do not roll back on error. This meant that an error between truncating and committing left the sequences out of sync with the table contents, with potentially bad consequences as were noted in a Warning on the TRUNCATE man page. To fix, create a new storage file (relfilenode) for a sequence that is to be reset due to RESTART IDENTITY. If the transaction aborts, we'll automatically revert to the old storage file. This acts just like a rewriting ALTER TABLE operation. A penalty is that we have to take exclusive lock on the sequence, but since we've already got exclusive lock on its owning table, that seems unlikely to be much of a problem. The interaction of this with usual nontransactional behaviors of sequence operations is a bit weird, but it's hard to see what would be completely consistent. Our choice is to discard cached-but-unissued sequence values both when the RESTART is executed, and at rollback if any; but to not touch the currval() state either time. In passing, move the sequence reset operations to happen before not after any AFTER TRUNCATE triggers are fired. The previous ordering was not logically sensible, but was forced by the need to minimize inconsistency if the triggers caused an error. Transactional rollback is a much better solution to that. Patch by Steve Singer, rather heavily adjusted by me.
2010-11-17 22:42:18 +01:00
/*
* Restart owned sequences if we were asked to.
*/
foreach(cell, seq_relids)
{
Oid seq_relid = lfirst_oid(cell);
ResetSequence(seq_relid);
}
Support statement-level ON TRUNCATE triggers. Simon Riggs
2008-03-28 01:21:56 +01:00
/*
* Process all AFTER STATEMENT TRUNCATE triggers.
*/
resultRelInfo = resultRelInfos;
foreach(cell, rels)
{
estate->es_result_relation_info = resultRelInfo;
ExecASTruncateTriggers(estate, resultRelInfo);
resultRelInfo++;
}
/* Handle queued AFTER triggers */
AfterTriggerEndQuery(estate);
/* We can clean up the EState now */
FreeExecutorState(estate);
Fix my brain fade in TRUNCATE triggers patch: can't release relcache refcounts while EState still contains pointers to those relations. Exposed by the CLOBBER_CACHE_ALWAYS tests that buildfarm member jaguar is running (I knew those cycles would pay off...)
2008-03-31 05:34:27 +02:00
/* And close the rels (can't do this while EState still holds refs) */
foreach(cell, rels)
{
Relation rel = (Relation) lfirst(cell);
heap_close(rel, NoLock);
}
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
}
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
Dept. of second thoughts: rejigger the TRUNCATE ... CASCADE patch so that 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.
2006-03-03 19:25:14 +01:00
/*
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* Check that a given rel is safe to truncate. Subroutine for ExecuteTruncate
Dept. of second thoughts: rejigger the TRUNCATE ... CASCADE patch so that 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.
2006-03-03 19:25:14 +01:00
*/
static void
truncate_check_rel(Relation rel)
{
Create a separate grantable privilege for TRUNCATE, rather than having it be always owner-only. The TRUNCATE privilege works identically to the DELETE privilege so far as interactions with the rest of the system go. Robert Haas
2008-09-08 02:47:41 +02:00
AclResult aclresult;
Dept. of second thoughts: rejigger the TRUNCATE ... CASCADE patch so that 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.
2006-03-03 19:25:14 +01:00
/* Only allow truncate on regular tables */
if (rel->rd_rel->relkind != RELKIND_RELATION)
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("\"%s\" is not a table",
RelationGetRelationName(rel))));
/* Permissions checks */
Create a separate grantable privilege for TRUNCATE, rather than having it be always owner-only. The TRUNCATE privilege works identically to the DELETE privilege so far as interactions with the rest of the system go. Robert Haas
2008-09-08 02:47:41 +02:00
aclresult = pg_class_aclcheck(RelationGetRelid(rel), GetUserId(),
ACL_TRUNCATE);
if (aclresult != ACLCHECK_OK)
aclcheck_error(aclresult, ACL_KIND_CLASS,
Dept. of second thoughts: rejigger the TRUNCATE ... CASCADE patch so that 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.
2006-03-03 19:25:14 +01:00
RelationGetRelationName(rel));
if (!allowSystemTableMods && IsSystemRelation(rel))
ereport(ERROR,
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
errmsg("permission denied: \"%s\" is a system catalog",
RelationGetRelationName(rel))));
/*
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* Don't allow truncate on temp tables of other backends ... their local
* buffer manager is not going to cope.
Dept. of second thoughts: rejigger the TRUNCATE ... CASCADE patch so that 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.
2006-03-03 19:25:14 +01:00
*/
Modify the relcache to record the temp status of both local and nonlocal temp relations; this is no more expensive than before, now that we have pg_class.relistemp. Insert tests into bufmgr.c to prevent attempting to fetch pages from nonlocal temp relations. This provides a low-level defense against bugs-of-omission allowing temp pages to be loaded into shared buffers, as in the contrib/pgstattuple problem reported by Stuart Bishop. While at it, tweak a bunch of places to use new relcache tests (instead of expensive probes into pg_namespace) to detect local or nonlocal temp tables.
2009-04-01 00:12:48 +02:00
if (RELATION_IS_OTHER_TEMP(rel))
Dept. of second thoughts: rejigger the TRUNCATE ... CASCADE patch so that 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.
2006-03-03 19:25:14 +01:00
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
errmsg("cannot truncate temporary tables of other sessions")));
Forbid ALTER TABLE and CLUSTER when there are pending AFTER-trigger events in the current backend for the target table. These operations move tuples around and would thus invalidate the TIDs stored in the trigger event records. (We need not worry about events in other backends, since acquiring exclusive lock should be enough to ensure there aren't any.) It might be sufficient to forbid only the table-rewriting variants of ALTER TABLE, but in the absence of any compelling use-case, let's just be safe and simple. Per follow-on investigation of bug #3847, though this is not actually the same problem reported therein. Possibly this should be back-patched, but since the case has never been reported from the field, I didn't bother.
2008-01-03 00:34:42 +01:00
/*
Add checks to TRUNCATE, CLUSTER, and REINDEX to prevent performing these operations when the current transaction has any open references to the target relation or index (implying it has an active query using the relation). The need for this was previously recognized in connection with ALTER TABLE, but anything that summarily eliminates tuples or moves them around would confuse an active scan. While this patch does not in itself fix bug #3883 (the deadlock would happen before the new check fires), it will discourage people from attempting the sequence of operations that creates a deadlock risk, so it's at least a partial response to that problem. In passing, add a previously-missing check to REINDEX to prevent trying to reindex another backend's temp table. This isn't a security problem since only a superuser would get past the schema permission checks, but if we are testing for this in other utility commands then surely REINDEX should too.
2008-01-30 20:46:48 +01:00
* Also check for active uses of the relation in the current transaction,
* including open scans and pending AFTER trigger events.
Forbid ALTER TABLE and CLUSTER when there are pending AFTER-trigger events in the current backend for the target table. These operations move tuples around and would thus invalidate the TIDs stored in the trigger event records. (We need not worry about events in other backends, since acquiring exclusive lock should be enough to ensure there aren't any.) It might be sufficient to forbid only the table-rewriting variants of ALTER TABLE, but in the absence of any compelling use-case, let's just be safe and simple. Per follow-on investigation of bug #3847, though this is not actually the same problem reported therein. Possibly this should be back-patched, but since the case has never been reported from the field, I didn't bother.
2008-01-03 00:34:42 +01:00
*/
Add checks to TRUNCATE, CLUSTER, and REINDEX to prevent performing these operations when the current transaction has any open references to the target relation or index (implying it has an active query using the relation). The need for this was previously recognized in connection with ALTER TABLE, but anything that summarily eliminates tuples or moves them around would confuse an active scan. While this patch does not in itself fix bug #3883 (the deadlock would happen before the new check fires), it will discourage people from attempting the sequence of operations that creates a deadlock risk, so it's at least a partial response to that problem. In passing, add a previously-missing check to REINDEX to prevent trying to reindex another backend's temp table. This isn't a security problem since only a superuser would get past the schema permission checks, but if we are testing for this in other utility commands then surely REINDEX should too.
2008-01-30 20:46:48 +01:00
CheckTableNotInUse(rel, "TRUNCATE");
Dept. of second thoughts: rejigger the TRUNCATE ... CASCADE patch so that 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.
2006-03-03 19:25:14 +01:00
}
Code review for LIKE INCLUDING patch --- clean up some cosmetic and not so cosmetic stuff.
2009-10-13 02:53:08 +02:00
/*
CREATE LIKE INCLUDING COMMENTS and STORAGE, and INCLUDING ALL shortcut. Itagaki Takahiro.
2009-10-12 21:49:24 +02:00
* storage_name
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* returns the name corresponding to a typstorage/attstorage enum value
CREATE LIKE INCLUDING COMMENTS and STORAGE, and INCLUDING ALL shortcut. Itagaki Takahiro.
2009-10-12 21:49:24 +02:00
*/
static const char *
storage_name(char c)
{
switch (c)
{
Code review for LIKE INCLUDING patch --- clean up some cosmetic and not so cosmetic stuff.
2009-10-13 02:53:08 +02:00
case 'p':
return "PLAIN";
case 'm':
return "MAIN";
case 'x':
return "EXTENDED";
case 'e':
return "EXTERNAL";
default:
return "???";
CREATE LIKE INCLUDING COMMENTS and STORAGE, and INCLUDING ALL shortcut. Itagaki Takahiro.
2009-10-12 21:49:24 +02:00
}
}
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*----------
* MergeAttributes
* Returns new schema given initial schema and superclasses.
*
* Input arguments:
* 'schema' is the column/attribute definition for the table. (It's a list
* of ColumnDef's.) It is destructively changed.
* 'supers' is a list of names (as RangeVar nodes) of parent relations.
Fix a comment for MergeAttributes. We forgot to adjust it when we changed relistemp to relpersistence.
2011-02-07 08:51:39 +01:00
* 'relpersistence' is a persistence type of the table.
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*
* Output arguments:
Create a distinction between Lists of integers and Lists of OIDs, to get rid of the assumption that sizeof(Oid)==sizeof(int). This is one small step towards someday supporting 8-byte OIDs. For the moment, it doesn't do much except get rid of a lot of unsightly casts.
2003-02-09 07:56:28 +01:00
* 'supOids' receives a list of the OIDs of the parent relations.
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
* 'supconstr' receives a list of constraints belonging to the parents,
* updated as necessary to be valid for the child.
Upgrade ALTER TABLE DROP COLUMN so that it can drop an OID column, and remove separate implementation of ALTER TABLE SET WITHOUT OIDS in favor of doing a regular DROP. Also, cause CREATE TABLE to account completely correctly for the inheritance status of the OID column. This fixes problems with dropping OID columns that have dependencies, as noted by Christopher Kings-Lynne, as well as making sure that you can't drop an OID column that was inherited from a parent.
2004-03-23 20:35:17 +01:00
* 'supOidCount' is set to the number of parents that have OID columns.
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*
* Return value:
* Completed schema list.
*
* Notes:
* The order in which the attributes are inherited is very important.
* Intuitively, the inherited attributes should come first. If a table
* inherits from multiple parents, the order of those attributes are
* according to the order of the parents specified in CREATE TABLE.
*
* Here's an example:
*
* create table person (name text, age int4, location point);
* create table emp (salary int4, manager text) inherits(person);
* create table student (gpa float8) inherits (person);
* create table stud_emp (percent int4) inherits (emp, student);
*
* The order of the attributes of stud_emp is:
*
* person {1:name, 2:age, 3:location}
* / \
* {6:gpa} student emp {4:salary, 5:manager}
* \ /
* stud_emp {7:percent}
*
* If the same attribute name appears multiple times, then it appears
* in the result table in the proper location for its first appearance.
*
* Constraints (including NOT NULL constraints) for the child table
* are the union of all relevant constraints, from both the child schema
* and parent tables.
*
* The default value for a child column is defined as:
* (1) If the child schema specifies a default, that value is used.
* (2) If neither the child nor any parent specifies a default, then
* the column will not have a default.
* (3) If conflicting defaults are inherited from different parents
* (and not overridden by the child), an error is raised.
* (4) Otherwise the inherited default is used.
* Rule (3) is new in Postgres 7.1; in earlier releases you got a
* rather arbitrary choice of which parent default to use.
*----------
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
*/
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
static List *
Generalize concept of temporary relations to "relation persistence". This commit replaces pg_class.relistemp with pg_class.relpersistence; and also modifies the RangeVar node type to carry relpersistence rather than istemp. It also removes removes rd_istemp from RelationData and instead performs the correct computation based on relpersistence. For clarity, we add three new macros: RelationNeedsWAL(), RelationUsesLocalBuffers(), and RelationUsesTempNamespace(), so that we can clarify the purpose of each check that previous depended on rd_istemp. This is intended as infrastructure for the upcoming unlogged tables patch, as well as for future possible work on global temporary tables.
2010-12-13 18:34:26 +01:00
MergeAttributes(List *schema, List *supers, char relpersistence,
Upgrade ALTER TABLE DROP COLUMN so that it can drop an OID column, and remove separate implementation of ALTER TABLE SET WITHOUT OIDS in favor of doing a regular DROP. Also, cause CREATE TABLE to account completely correctly for the inheritance status of the OID column. This fixes problems with dropping OID columns that have dependencies, as noted by Christopher Kings-Lynne, as well as making sure that you can't drop an OID column that was inherited from a parent.
2004-03-23 20:35:17 +01:00
List **supOids, List **supconstr, int *supOidCount)
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
{
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *entry;
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
List *inhSchema = NIL;
List *parentOids = NIL;
List *constraints = NIL;
Upgrade ALTER TABLE DROP COLUMN so that it can drop an OID column, and remove separate implementation of ALTER TABLE SET WITHOUT OIDS in favor of doing a regular DROP. Also, cause CREATE TABLE to account completely correctly for the inheritance status of the OID column. This fixes problems with dropping OID columns that have dependencies, as noted by Christopher Kings-Lynne, as well as making sure that you can't drop an OID column that was inherited from a parent.
2004-03-23 20:35:17 +01:00
int parentsWithOids = 0;
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
bool have_bogus_defaults = false;
int child_attno;
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
static Node bogus_marker = {0}; /* marks conflicting defaults */
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
Prevent a backend crash when processing CREATE TABLE commands with more than 65K columns, or when the created table has more than 65K columns due to adding inherited columns from parent relations. Fix a similar crash when processing SELECT queries with more than 65K target list entries. In all three cases we would eventually detect the error and elog, but the check was being made too late.
2004-11-17 00:34:26 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Check for and reject tables with too many columns. We perform this
* check relatively early for two reasons: (a) we don't run the risk of
* overflowing an AttrNumber in subsequent code (b) an O(n^2) algorithm is
* okay if we're processing <= 1600 columns, but could take minutes to
* execute if the user attempts to create a table with hundreds of
* thousands of columns.
Prevent a backend crash when processing CREATE TABLE commands with more than 65K columns, or when the created table has more than 65K columns due to adding inherited columns from parent relations. Fix a similar crash when processing SELECT queries with more than 65K target list entries. In all three cases we would eventually detect the error and elog, but the check was being made too late.
2004-11-17 00:34:26 +01:00
*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Note that we also need to check that any we do not exceed this figure
* after including columns from inherited relations.
Prevent a backend crash when processing CREATE TABLE commands with more than 65K columns, or when the created table has more than 65K columns due to adding inherited columns from parent relations. Fix a similar crash when processing SELECT queries with more than 65K target list entries. In all three cases we would eventually detect the error and elog, but the check was being made too late.
2004-11-17 00:34:26 +01:00
*/
if (list_length(schema) > MaxHeapAttributeNumber)
ereport(ERROR,
(errcode(ERRCODE_TOO_MANY_COLUMNS),
errmsg("tables can have at most %d columns",
MaxHeapAttributeNumber)));
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
/*
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
* Check for duplicate names in the explicit list of attributes.
*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Although we might consider merging such entries in the same way that we
* handle name conflicts for inherited attributes, it seems to make more
* sense to assume such conflicts are errors.
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
*/
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
foreach(entry, schema)
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
{
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
ColumnDef *coldef = lfirst(entry);
Type table feature This adds the CREATE TABLE name OF type command, per SQL standard.
2010-01-29 00:21:13 +01:00
ListCell *rest = lnext(entry);
ListCell *prev = entry;
if (coldef->typeName == NULL)
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
Type table feature This adds the CREATE TABLE name OF type command, per SQL standard.
2010-01-29 00:21:13 +01:00
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* Typed table column option that does not belong to a column from
* the type. This works because the columns from the type come
* first in the list.
Type table feature This adds the CREATE TABLE name OF type command, per SQL standard.
2010-01-29 00:21:13 +01:00
*/
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_COLUMN),
errmsg("column \"%s\" does not exist",
coldef->colname)));
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
Type table feature This adds the CREATE TABLE name OF type command, per SQL standard.
2010-01-29 00:21:13 +01:00
while (rest != NULL)
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
{
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
ColumnDef *restdef = lfirst(rest);
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
ListCell *next = lnext(rest); /* need to save it in case we
* delete it */
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
if (strcmp(coldef->colname, restdef->colname) == 0)
Type table feature This adds the CREATE TABLE name OF type command, per SQL standard.
2010-01-29 00:21:13 +01:00
{
if (coldef->is_from_type)
{
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
/*
* merge the column options into the column from the type
*/
Type table feature This adds the CREATE TABLE name OF type command, per SQL standard.
2010-01-29 00:21:13 +01:00
coldef->is_not_null = restdef->is_not_null;
coldef->raw_default = restdef->raw_default;
coldef->cooked_default = restdef->cooked_default;
coldef->constraints = restdef->constraints;
coldef->is_from_type = false;
list_delete_cell(schema, rest, prev);
}
else
ereport(ERROR,
(errcode(ERRCODE_DUPLICATE_COLUMN),
errmsg("column \"%s\" specified more than once",
coldef->colname)));
}
prev = rest;
rest = next;
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
}
}
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Scan the parents left-to-right, and merge their attributes to form a
* list of inherited attributes (inhSchema). Also check to see if we need
* to inherit an OID column.
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
*/
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
child_attno = 0;
foreach(entry, supers)
{
RangeVar *parent = (RangeVar *) lfirst(entry);
Relation relation;
TupleDesc tupleDesc;
TupleConstr *constr;
AttrNumber *newattno;
AttrNumber parent_attno;
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
Fix possible "tuple concurrently updated" error in ALTER TABLE. 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.
2011-03-19 03:09:57 +01:00
/*
* A self-exclusive lock is needed here. If two backends attempt to
* add children to the same parent simultaneously, and that parent has
* no pre-existing children, then both will attempt to update the
* parent's relhassubclass field, leading to a "tuple concurrently
Teach ANALYZE to clear pg_class.relhassubclass when appropriate. 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.
2011-09-02 20:29:31 +02:00
* updated" error. Also, this interlocks against a concurrent ANALYZE
* on the parent table, which might otherwise be attempting to clear
* the parent's relhassubclass field, if its previous children were
* recently dropped.
Fix possible "tuple concurrently updated" error in ALTER TABLE. 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.
2011-03-19 03:09:57 +01:00
*/
relation = heap_openrv(parent, ShareUpdateExclusiveLock);
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
if (relation->rd_rel->relkind != RELKIND_RELATION)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("inherited relation \"%s\" is not a table",
parent->relname)));
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/* Permanent rels cannot inherit from temporary ones */
Fix failure to ignore leftover temp tables after a server crash. During crash recovery, we remove disk files belonging to temporary tables, but the system catalog entries for such tables are intentionally not cleaned up right away. Instead, the first backend that uses a temp schema is expected to clean out any leftover objects therein. This approach requires that we be careful to ignore leftover temp tables (since any actual access attempt would fail), *even if their BackendId matches our session*, if we have not yet established use of the session's corresponding temp schema. That worked fine in the past, but was broken by commit debcec7dc31a992703911a9953e299c8d730c778 which incorrectly removed the rd_islocaltemp relcache flag. Put it back, and undo various changes that substituted tests like "rel->rd_backend == MyBackendId" for use of a state-aware flag. Per trouble report from Heikki Linnakangas. Back-patch to 9.1 where the erroneous change was made. In the back branches, be careful to add rd_islocaltemp in a spot in the struct that was alignment padding before, so as not to break existing add-on code.
2012-12-18 02:15:32 +01:00
if (relpersistence != RELPERSISTENCE_TEMP &&
relation->rd_rel->relpersistence == RELPERSISTENCE_TEMP)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("cannot inherit from temporary relation \"%s\"",
parent->relname)));
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
Fix failure to ignore leftover temp tables after a server crash. During crash recovery, we remove disk files belonging to temporary tables, but the system catalog entries for such tables are intentionally not cleaned up right away. Instead, the first backend that uses a temp schema is expected to clean out any leftover objects therein. This approach requires that we be careful to ignore leftover temp tables (since any actual access attempt would fail), *even if their BackendId matches our session*, if we have not yet established use of the session's corresponding temp schema. That worked fine in the past, but was broken by commit debcec7dc31a992703911a9953e299c8d730c778 which incorrectly removed the rd_islocaltemp relcache flag. Put it back, and undo various changes that substituted tests like "rel->rd_backend == MyBackendId" for use of a state-aware flag. Per trouble report from Heikki Linnakangas. Back-patch to 9.1 where the erroneous change was made. In the back branches, be careful to add rd_islocaltemp in a spot in the struct that was alignment padding before, so as not to break existing add-on code.
2012-12-18 02:15:32 +01:00
/* If existing rel is temp, it must belong to this session */
if (relation->rd_rel->relpersistence == RELPERSISTENCE_TEMP &&
!relation->rd_islocaltemp)
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("cannot inherit from temporary relation of another session")));
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
* We should have an UNDER permission flag for this, but for now,
* demand that creator of a child table own the parent.
*/
if (!pg_class_ownercheck(RelationGetRelid(relation), GetUserId()))
Adjust 'permission denied' messages to be more useful and consistent.
2003-08-01 02:15:26 +02:00
aclcheck_error(ACLCHECK_NOT_OWNER, ACL_KIND_CLASS,
Restructure aclcheck error reporting to make permission-failure messages more uniform and internationalizable: the global array aclcheck_error_strings[] is gone in favor of a subroutine aclcheck_error(). Partial implementation of namespace-related permission checks --- not all done yet.
2002-04-27 05:45:03 +02:00
RelationGetRelationName(relation));
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
* Reject duplications in the list of parents.
*/
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
if (list_member_oid(parentOids, RelationGetRelid(relation)))
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_DUPLICATE_TABLE),
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
errmsg("relation \"%s\" would be inherited from more than once",
parent->relname)));
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
parentOids = lappend_oid(parentOids, RelationGetRelid(relation));
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
Upgrade ALTER TABLE DROP COLUMN so that it can drop an OID column, and remove separate implementation of ALTER TABLE SET WITHOUT OIDS in favor of doing a regular DROP. Also, cause CREATE TABLE to account completely correctly for the inheritance status of the OID column. This fixes problems with dropping OID columns that have dependencies, as noted by Christopher Kings-Lynne, as well as making sure that you can't drop an OID column that was inherited from a parent.
2004-03-23 20:35:17 +01:00
if (relation->rd_rel->relhasoids)
parentsWithOids++;
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
tupleDesc = RelationGetDescr(relation);
constr = tupleDesc->constr;
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* newattno[] will contain the child-table attribute numbers for the
* attributes of this parent table. (They are not the same for
* parents after the first one, nor if we have dropped columns.)
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*/
Prevent palloc(0) error when parent table has zero columns.
2003-04-21 17:19:55 +02:00
newattno = (AttrNumber *)
Prevent CREATE TABLE LIKE/INHERITS from (mis) copying whole-row Vars. If a CHECK constraint or index definition contained a whole-row Var (that is, "table.*"), an attempt to copy that definition via CREATE TABLE LIKE or table inheritance produced incorrect results: the copied Var still claimed to have the rowtype of the source table, rather than the created table. For the LIKE case, it seems reasonable to just throw error for this situation, since the point of LIKE is that the new table is not permanently coupled to the old, so there's no reason to assume its rowtype will stay compatible. In the inheritance case, we should ideally allow such constraints, but doing so will require nontrivial refactoring of CREATE TABLE processing (because we'd need to know the OID of the new table's rowtype before we adjust inherited CHECK constraints). In view of the lack of previous complaints, that doesn't seem worth the risk in a back-patched bug fix, so just make it throw error for the inheritance case as well. Along the way, replace change_varattnos_of_a_node() with a more robust function map_variable_attnos(), which is capable of being extended to handle insertion of ConvertRowtypeExpr whenever we get around to fixing the inheritance case nicely, and in the meantime it returns a failure indication to the caller so that a helpful message with some context can be thrown. Also, this code will do the right thing with subselects (if we ever allow them in CHECK or indexes), and it range-checks varattnos before using them to index into the map array. Per report from Sergey Konoplev. Back-patch to all supported branches.
2012-06-30 22:43:50 +02:00
palloc0(tupleDesc->natts * sizeof(AttrNumber));
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
for (parent_attno = 1; parent_attno <= tupleDesc->natts;
parent_attno++)
{
Form_pg_attribute attribute = tupleDesc->attrs[parent_attno - 1];
char *attributeName = NameStr(attribute->attname);
int exist_attno;
ColumnDef *def;
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
ALTER TABLE DROP COLUMN works. Patch by Christopher Kings-Lynne, code review by Tom Lane. Remaining issues: functions that take or return tuple types are likely to break if one drops (or adds!) a column in the table defining the type. Need to think about what to do here. Along the way: some code review for recent COPY changes; mark system columns attnotnull = true where appropriate, per discussion a month ago.
2002-08-02 20:15:10 +02:00
/*
* Ignore dropped columns in the parent.
*/
if (attribute->attisdropped)
Prevent CREATE TABLE LIKE/INHERITS from (mis) copying whole-row Vars. If a CHECK constraint or index definition contained a whole-row Var (that is, "table.*"), an attempt to copy that definition via CREATE TABLE LIKE or table inheritance produced incorrect results: the copied Var still claimed to have the rowtype of the source table, rather than the created table. For the LIKE case, it seems reasonable to just throw error for this situation, since the point of LIKE is that the new table is not permanently coupled to the old, so there's no reason to assume its rowtype will stay compatible. In the inheritance case, we should ideally allow such constraints, but doing so will require nontrivial refactoring of CREATE TABLE processing (because we'd need to know the OID of the new table's rowtype before we adjust inherited CHECK constraints). In view of the lack of previous complaints, that doesn't seem worth the risk in a back-patched bug fix, so just make it throw error for the inheritance case as well. Along the way, replace change_varattnos_of_a_node() with a more robust function map_variable_attnos(), which is capable of being extended to handle insertion of ConvertRowtypeExpr whenever we get around to fixing the inheritance case nicely, and in the meantime it returns a failure indication to the caller so that a helpful message with some context can be thrown. Also, this code will do the right thing with subselects (if we ever allow them in CHECK or indexes), and it range-checks varattnos before using them to index into the map array. Per report from Sergey Konoplev. Back-patch to all supported branches.
2012-06-30 22:43:50 +02:00
continue; /* leave newattno entry as zero */
ALTER TABLE DROP COLUMN works. Patch by Christopher Kings-Lynne, code review by Tom Lane. Remaining issues: functions that take or return tuple types are likely to break if one drops (or adds!) a column in the table defining the type. Need to think about what to do here. Along the way: some code review for recent COPY changes; mark system columns attnotnull = true where appropriate, per discussion a month ago.
2002-08-02 20:15:10 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
* Does it conflict with some previously inherited column?
*/
exist_attno = findAttrByName(attributeName, inhSchema);
if (exist_attno > 0)
{
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
Oid defTypeId;
int32 deftypmod;
Per-column collation support 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
2011-02-08 22:04:18 +01:00
Oid defCollId;
Support type modifiers for user-defined types, and pull most knowledge about typmod representation for standard types out into type-specific typmod I/O functions. Teodor Sigaev, with some editorialization by Tom Lane.
2006-12-30 22:21:56 +01:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
* Yes, try to merge the two column definitions. They must
Add check for matching column collations in ALTER TABLE ... INHERIT. 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.
2011-04-17 22:22:13 +02:00
* have the same type, typmod, and collation.
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*/
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(NOTICE,
Message editing: remove gratuitous variations in message wording, standardize terms, add some clarifications, fix some untranslatable attempts at dynamic message building.
2003-09-25 08:58:07 +02:00
(errmsg("merging multiple inherited definitions of column \"%s\"",
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
attributeName)));
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
def = (ColumnDef *) list_nth(inhSchema, exist_attno - 1);
Remove collation information from TypeName, where it does not belong. 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.
2011-03-10 04:38:52 +01:00
typenameTypeIdAndMod(NULL, def->typeName, &defTypeId, &deftypmod);
Support type modifiers for user-defined types, and pull most knowledge about typmod representation for standard types out into type-specific typmod I/O functions. Teodor Sigaev, with some editorialization by Tom Lane.
2006-12-30 22:21:56 +01:00
if (defTypeId != attribute->atttypid ||
deftypmod != attribute->atttypmod)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("inherited column \"%s\" has a type conflict",
attributeName),
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
errdetail("%s versus %s",
Make backend header files C++ safe This alters various incidental uses of C++ key words to use other similar identifiers, so that a C++ compiler won't choke outright. You still (probably) need extern "C" { }; around the inclusion of backend headers. based on a patch by Kurt Harriman <harriman@acm.org> Also add a script cpluspluscheck to check for C++ compatibility in the future. As of right now, this passes without error for me.
2009-07-16 08:33:46 +02:00
TypeNameToString(def->typeName),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
format_type_be(attribute->atttypid))));
Remove collation information from TypeName, where it does not belong. 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.
2011-03-10 04:38:52 +01:00
defCollId = GetColumnDefCollation(NULL, def, defTypeId);
Per-column collation support 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
2011-02-08 22:04:18 +01:00
if (defCollId != attribute->attcollation)
ereport(ERROR,
(errcode(ERRCODE_COLLATION_MISMATCH),
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
errmsg("inherited column \"%s\" has a collation conflict",
attributeName),
Per-column collation support 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
2011-02-08 22:04:18 +01:00
errdetail("\"%s\" versus \"%s\"",
get_collation_name(defCollId),
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
get_collation_name(attribute->attcollation))));
CREATE LIKE INCLUDING COMMENTS and STORAGE, and INCLUDING ALL shortcut. Itagaki Takahiro.
2009-10-12 21:49:24 +02:00
/* Copy storage parameter */
if (def->storage == 0)
def->storage = attribute->attstorage;
else if (def->storage != attribute->attstorage)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
errmsg("inherited column \"%s\" has a storage parameter conflict",
attributeName),
errdetail("%s versus %s",
storage_name(def->storage),
storage_name(attribute->attstorage))));
CREATE LIKE INCLUDING COMMENTS and STORAGE, and INCLUDING ALL shortcut. Itagaki Takahiro.
2009-10-12 21:49:24 +02:00
Replace pg_attribute.attisinherited with attislocal and attinhcount columns, to allow more correct behavior in multiple-inheritance cases. Patch by Alvaro Herrera, review by Tom Lane.
2002-09-22 21:42:52 +02:00
def->inhcount++;
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/* Merge of NOT NULL constraints = OR 'em together */
def->is_not_null |= attribute->attnotnull;
/* Default and other constraints are handled below */
newattno[parent_attno - 1] = exist_attno;
}
else
{
/*
* No, create a new inherited column
*/
def = makeNode(ColumnDef);
def->colname = pstrdup(attributeName);
Make backend header files C++ safe This alters various incidental uses of C++ key words to use other similar identifiers, so that a C++ compiler won't choke outright. You still (probably) need extern "C" { }; around the inclusion of backend headers. based on a patch by Kurt Harriman <harriman@acm.org> Also add a script cpluspluscheck to check for C++ compatibility in the future. As of right now, this passes without error for me.
2009-07-16 08:33:46 +02:00
def->typeName = makeTypeNameFromOid(attribute->atttypid,
Remove collation information from TypeName, where it does not belong. 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.
2011-03-10 04:38:52 +01:00
attribute->atttypmod);
Replace pg_attribute.attisinherited with attislocal and attinhcount columns, to allow more correct behavior in multiple-inheritance cases. Patch by Alvaro Herrera, review by Tom Lane.
2002-09-22 21:42:52 +02:00
def->inhcount = 1;
def->is_local = false;
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
def->is_not_null = attribute->attnotnull;
Remove collation information from TypeName, where it does not belong. 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.
2011-03-10 04:38:52 +01:00
def->is_from_type = false;
Code review for LIKE INCLUDING patch --- clean up some cosmetic and not so cosmetic stuff.
2009-10-13 02:53:08 +02:00
def->storage = attribute->attstorage;
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
def->raw_default = NULL;
def->cooked_default = NULL;
Remove collation information from TypeName, where it does not belong. 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.
2011-03-10 04:38:52 +01:00
def->collClause = NULL;
def->collOid = attribute->attcollation;
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
def->constraints = NIL;
inhSchema = lappend(inhSchema, def);
newattno[parent_attno - 1] = ++child_attno;
}
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
* Copy default if any
*/
if (attribute->atthasdef)
{
Change CREATE TABLE so that column default expressions coming from different inheritance parent tables are compared using equal(), instead of doing strcmp() on the nodeToString representation. The old implementation was always a tad cheesy, and it finally fails completely as of 8.4, now that the node tree might contain syntax location information. equal() knows it's supposed to ignore those fields, but strcmp() hardly can. Per recent report from Scott Ribe.
2009-10-06 02:55:26 +02:00
Node *this_default = NULL;
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
AttrDefault *attrdef;
int i;
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/* Find default in constraint structure */
Assert(constr != NULL);
attrdef = constr->defval;
for (i = 0; i < constr->num_defval; i++)
{
if (attrdef[i].adnum == parent_attno)
{
Change CREATE TABLE so that column default expressions coming from different inheritance parent tables are compared using equal(), instead of doing strcmp() on the nodeToString representation. The old implementation was always a tad cheesy, and it finally fails completely as of 8.4, now that the node tree might contain syntax location information. equal() knows it's supposed to ignore those fields, but strcmp() hardly can. Per recent report from Scott Ribe.
2009-10-06 02:55:26 +02:00
this_default = stringToNode(attrdef[i].adbin);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
break;
}
}
Assert(this_default != NULL);
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* If default expr could contain any vars, we'd need to fix
* 'em, but it can't; so default is ready to apply to child.
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
* If we already had a default from some prior parent, check
* to see if they are the same. If so, no problem; if not,
* mark the column as having a bogus default. Below, we will
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* complain if the bogus default isn't overridden by the child
* schema.
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*/
Assert(def->raw_default == NULL);
if (def->cooked_default == NULL)
Change CREATE TABLE so that column default expressions coming from different inheritance parent tables are compared using equal(), instead of doing strcmp() on the nodeToString representation. The old implementation was always a tad cheesy, and it finally fails completely as of 8.4, now that the node tree might contain syntax location information. equal() knows it's supposed to ignore those fields, but strcmp() hardly can. Per recent report from Scott Ribe.
2009-10-06 02:55:26 +02:00
def->cooked_default = this_default;
else if (!equal(def->cooked_default, this_default))
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
{
Change CREATE TABLE so that column default expressions coming from different inheritance parent tables are compared using equal(), instead of doing strcmp() on the nodeToString representation. The old implementation was always a tad cheesy, and it finally fails completely as of 8.4, now that the node tree might contain syntax location information. equal() knows it's supposed to ignore those fields, but strcmp() hardly can. Per recent report from Scott Ribe.
2009-10-06 02:55:26 +02:00
def->cooked_default = &bogus_marker;
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
have_bogus_defaults = true;
}
}
}
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
* Now copy the CHECK constraints of this parent, adjusting attnos
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* using the completed newattno[] map. Identically named constraints
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
* are merged if possible, else we throw error.
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*/
if (constr && constr->num_check > 0)
{
ConstrCheck *check = constr->check;
int i;
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
for (i = 0; i < constr->num_check; i++)
{
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
char *name = check[i].ccname;
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
Node *expr;
Prevent CREATE TABLE LIKE/INHERITS from (mis) copying whole-row Vars. If a CHECK constraint or index definition contained a whole-row Var (that is, "table.*"), an attempt to copy that definition via CREATE TABLE LIKE or table inheritance produced incorrect results: the copied Var still claimed to have the rowtype of the source table, rather than the created table. For the LIKE case, it seems reasonable to just throw error for this situation, since the point of LIKE is that the new table is not permanently coupled to the old, so there's no reason to assume its rowtype will stay compatible. In the inheritance case, we should ideally allow such constraints, but doing so will require nontrivial refactoring of CREATE TABLE processing (because we'd need to know the OID of the new table's rowtype before we adjust inherited CHECK constraints). In view of the lack of previous complaints, that doesn't seem worth the risk in a back-patched bug fix, so just make it throw error for the inheritance case as well. Along the way, replace change_varattnos_of_a_node() with a more robust function map_variable_attnos(), which is capable of being extended to handle insertion of ConvertRowtypeExpr whenever we get around to fixing the inheritance case nicely, and in the meantime it returns a failure indication to the caller so that a helpful message with some context can be thrown. Also, this code will do the right thing with subselects (if we ever allow them in CHECK or indexes), and it range-checks varattnos before using them to index into the map array. Per report from Sergey Konoplev. Back-patch to all supported branches.
2012-06-30 22:43:50 +02:00
bool found_whole_row;
ALTER TABLE SET/DROP NOT NULL, from Christopher Kings-Lynne.
2002-04-01 06:35:40 +02:00
Allow CHECK constraints to be declared ONLY This makes them enforceable only on the parent table, not on children tables. This is useful in various situations, per discussion involving people bitten by the restrictive behavior introduced in 8.4. Message-Id: 8762mp93iw.fsf@comcast.net CAFaPBrSMMpubkGf4zcRL_YL-AERUbYF_-ZNNYfb3CVwwEqc9TQ@mail.gmail.com Authors: Nikhil Sontakke, Alex Hunsaker Reviewed by Robert Haas and myself
2011-12-05 19:10:18 +01:00
/* ignore if the constraint is non-inheritable */
Recast "ONLY" column CHECK constraints as NO INHERIT The original syntax wasn't universally loved, and it didn't allow its usage in CREATE TABLE, only ALTER TABLE. It now works everywhere, and it also allows using ALTER TABLE ONLY to add an uninherited CHECK constraint, per discussion. The pg_constraint column has accordingly been renamed connoinherit. This commit partly reverts some of the changes in 61d81bd28dbec65a6b144e0cd3d0bfe25913c3ac, particularly some pg_dump and psql bits, because now pg_get_constraintdef includes the necessary NO INHERIT within the constraint definition. Author: Nikhil Sontakke Some tweaks by me
2012-04-21 04:46:20 +02:00
if (check[i].ccnoinherit)
Allow CHECK constraints to be declared ONLY This makes them enforceable only on the parent table, not on children tables. This is useful in various situations, per discussion involving people bitten by the restrictive behavior introduced in 8.4. Message-Id: 8762mp93iw.fsf@comcast.net CAFaPBrSMMpubkGf4zcRL_YL-AERUbYF_-ZNNYfb3CVwwEqc9TQ@mail.gmail.com Authors: Nikhil Sontakke, Alex Hunsaker Reviewed by Robert Haas and myself
2011-12-05 19:10:18 +01:00
continue;
Prevent CREATE TABLE LIKE/INHERITS from (mis) copying whole-row Vars. If a CHECK constraint or index definition contained a whole-row Var (that is, "table.*"), an attempt to copy that definition via CREATE TABLE LIKE or table inheritance produced incorrect results: the copied Var still claimed to have the rowtype of the source table, rather than the created table. For the LIKE case, it seems reasonable to just throw error for this situation, since the point of LIKE is that the new table is not permanently coupled to the old, so there's no reason to assume its rowtype will stay compatible. In the inheritance case, we should ideally allow such constraints, but doing so will require nontrivial refactoring of CREATE TABLE processing (because we'd need to know the OID of the new table's rowtype before we adjust inherited CHECK constraints). In view of the lack of previous complaints, that doesn't seem worth the risk in a back-patched bug fix, so just make it throw error for the inheritance case as well. Along the way, replace change_varattnos_of_a_node() with a more robust function map_variable_attnos(), which is capable of being extended to handle insertion of ConvertRowtypeExpr whenever we get around to fixing the inheritance case nicely, and in the meantime it returns a failure indication to the caller so that a helpful message with some context can be thrown. Also, this code will do the right thing with subselects (if we ever allow them in CHECK or indexes), and it range-checks varattnos before using them to index into the map array. Per report from Sergey Konoplev. Back-patch to all supported branches.
2012-06-30 22:43:50 +02:00
/* Adjust Vars to match new table's column numbering */
expr = map_variable_attnos(stringToNode(check[i].ccbin),
1, 0,
newattno, tupleDesc->natts,
&found_whole_row);
/*
pgindent run for release 9.3 This is the first run of the Perl-based pgindent script. Also update pgindent instructions.
2013-05-29 22:58:43 +02:00
* For the moment we have to reject whole-row variables. We
* could convert them, if we knew the new table's rowtype OID,
* but that hasn't been assigned yet.
Prevent CREATE TABLE LIKE/INHERITS from (mis) copying whole-row Vars. If a CHECK constraint or index definition contained a whole-row Var (that is, "table.*"), an attempt to copy that definition via CREATE TABLE LIKE or table inheritance produced incorrect results: the copied Var still claimed to have the rowtype of the source table, rather than the created table. For the LIKE case, it seems reasonable to just throw error for this situation, since the point of LIKE is that the new table is not permanently coupled to the old, so there's no reason to assume its rowtype will stay compatible. In the inheritance case, we should ideally allow such constraints, but doing so will require nontrivial refactoring of CREATE TABLE processing (because we'd need to know the OID of the new table's rowtype before we adjust inherited CHECK constraints). In view of the lack of previous complaints, that doesn't seem worth the risk in a back-patched bug fix, so just make it throw error for the inheritance case as well. Along the way, replace change_varattnos_of_a_node() with a more robust function map_variable_attnos(), which is capable of being extended to handle insertion of ConvertRowtypeExpr whenever we get around to fixing the inheritance case nicely, and in the meantime it returns a failure indication to the caller so that a helpful message with some context can be thrown. Also, this code will do the right thing with subselects (if we ever allow them in CHECK or indexes), and it range-checks varattnos before using them to index into the map array. Per report from Sergey Konoplev. Back-patch to all supported branches.
2012-06-30 22:43:50 +02:00
*/
if (found_whole_row)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
pgindent run for release 9.3 This is the first run of the Perl-based pgindent script. Also update pgindent instructions.
2013-05-29 22:58:43 +02:00
errmsg("cannot convert whole-row table reference"),
Prevent CREATE TABLE LIKE/INHERITS from (mis) copying whole-row Vars. If a CHECK constraint or index definition contained a whole-row Var (that is, "table.*"), an attempt to copy that definition via CREATE TABLE LIKE or table inheritance produced incorrect results: the copied Var still claimed to have the rowtype of the source table, rather than the created table. For the LIKE case, it seems reasonable to just throw error for this situation, since the point of LIKE is that the new table is not permanently coupled to the old, so there's no reason to assume its rowtype will stay compatible. In the inheritance case, we should ideally allow such constraints, but doing so will require nontrivial refactoring of CREATE TABLE processing (because we'd need to know the OID of the new table's rowtype before we adjust inherited CHECK constraints). In view of the lack of previous complaints, that doesn't seem worth the risk in a back-patched bug fix, so just make it throw error for the inheritance case as well. Along the way, replace change_varattnos_of_a_node() with a more robust function map_variable_attnos(), which is capable of being extended to handle insertion of ConvertRowtypeExpr whenever we get around to fixing the inheritance case nicely, and in the meantime it returns a failure indication to the caller so that a helpful message with some context can be thrown. Also, this code will do the right thing with subselects (if we ever allow them in CHECK or indexes), and it range-checks varattnos before using them to index into the map array. Per report from Sergey Konoplev. Back-patch to all supported branches.
2012-06-30 22:43:50 +02:00
errdetail("Constraint \"%s\" contains a whole-row reference to table \"%s\".",
name,
RelationGetRelationName(relation))));
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
/* check for duplicate */
if (!MergeCheckConstraint(constraints, name, expr))
{
/* nope, this is a new one */
CookedConstraint *cooked;
cooked = (CookedConstraint *) palloc(sizeof(CookedConstraint));
cooked->contype = CONSTR_CHECK;
cooked->name = pstrdup(name);
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
cooked->attnum = 0; /* not used for constraints */
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
cooked->expr = expr;
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
cooked->skip_validation = false;
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
cooked->is_local = false;
cooked->inhcount = 1;
Recast "ONLY" column CHECK constraints as NO INHERIT The original syntax wasn't universally loved, and it didn't allow its usage in CREATE TABLE, only ALTER TABLE. It now works everywhere, and it also allows using ALTER TABLE ONLY to add an uninherited CHECK constraint, per discussion. The pg_constraint column has accordingly been renamed connoinherit. This commit partly reverts some of the changes in 61d81bd28dbec65a6b144e0cd3d0bfe25913c3ac, particularly some pg_dump and psql bits, because now pg_get_constraintdef includes the necessary NO INHERIT within the constraint definition. Author: Nikhil Sontakke Some tweaks by me
2012-04-21 04:46:20 +02:00
cooked->is_no_inherit = false;
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
constraints = lappend(constraints, cooked);
}
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
}
}
Included all yacc and lex files into the distribution.
2000-01-16 21:05:00 +01:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
pfree(newattno);
Included all yacc and lex files into the distribution.
2000-01-16 21:05:00 +01:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Close the parent rel, but keep our AccessShareLock on it until xact
* commit. That will prevent someone else from deleting or ALTERing
* the parent before the child is committed.
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*/
heap_close(relation, NoLock);
}
Fix problem reported by Alex Korn: if a relation has been dropped and recreated since the start of our transaction, our first reference to it errored out because we'd try to reuse our old relcache entry for it. Do this by accepting SI inval messages just before relcache search in heap_openr, so that dead relcache entries will be flushed before we search. Also, break heap_open/openr into two pairs of routines, relation_open(r) and heap_open(r). The relation_open routines make no tests on relkind and so can be used to open anything that has a pg_class entry. The heap_open routines are wrappers that add a relkind test to preserve their established behavior. Use the relation_open routines in several places that had various kluge solutions for opening rels that might be either heap or index rels. Also, remove the old 'heap stats' code that's been superseded by Jan's stats collector, and clean up some inconsistencies in error reporting between the different types of ALTER TABLE.
2001-11-02 17:30:29 +01:00
Doc fix for INSERT ... (DEFAULT, ...) Appears I forgot to update the docs earlier. Rod Taylor
2002-04-24 04:38:58 +02:00
/*
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
* If we had no inherited attributes, the result schema is just the
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* explicitly declared columns. Otherwise, we need to merge the declared
* columns into the inherited schema list.
Doc fix for INSERT ... (DEFAULT, ...) Appears I forgot to update the docs earlier. Rod Taylor
2002-04-24 04:38:58 +02:00
*/
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
if (inhSchema != NIL)
{
foreach(entry, schema)
{
ColumnDef *newdef = lfirst(entry);
char *attributeName = newdef->colname;
int exist_attno;
Fix problem reported by Alex Korn: if a relation has been dropped and recreated since the start of our transaction, our first reference to it errored out because we'd try to reuse our old relcache entry for it. Do this by accepting SI inval messages just before relcache search in heap_openr, so that dead relcache entries will be flushed before we search. Also, break heap_open/openr into two pairs of routines, relation_open(r) and heap_open(r). The relation_open routines make no tests on relkind and so can be used to open anything that has a pg_class entry. The heap_open routines are wrappers that add a relkind test to preserve their established behavior. Use the relation_open routines in several places that had various kluge solutions for opening rels that might be either heap or index rels. Also, remove the old 'heap stats' code that's been superseded by Jan's stats collector, and clean up some inconsistencies in error reporting between the different types of ALTER TABLE.
2001-11-02 17:30:29 +01:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
* Does it conflict with some previously inherited column?
*/
exist_attno = findAttrByName(attributeName, inhSchema);
if (exist_attno > 0)
{
ColumnDef *def;
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
Oid defTypeId,
newTypeId;
int32 deftypmod,
newtypmod;
Per-column collation support 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
2011-02-08 22:04:18 +01:00
Oid defcollid,
newcollid;
Change the aclchk.c routines to uniformly use OIDs to identify the objects to be privilege-checked. Some change in their APIs would be necessary no matter what in the schema environment, and simply getting rid of the name-based interface entirely seems like the best way.
2002-03-22 00:27:25 +01:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
* Yes, try to merge the two column definitions. They must
Add check for matching column collations in ALTER TABLE ... INHERIT. 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.
2011-04-17 22:22:13 +02:00
* have the same type, typmod, and collation.
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*/
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(NOTICE,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
(errmsg("merging column \"%s\" with inherited definition",
attributeName)));
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
def = (ColumnDef *) list_nth(inhSchema, exist_attno - 1);
Remove collation information from TypeName, where it does not belong. 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.
2011-03-10 04:38:52 +01:00
typenameTypeIdAndMod(NULL, def->typeName, &defTypeId, &deftypmod);
typenameTypeIdAndMod(NULL, newdef->typeName, &newTypeId, &newtypmod);
Support type modifiers for user-defined types, and pull most knowledge about typmod representation for standard types out into type-specific typmod I/O functions. Teodor Sigaev, with some editorialization by Tom Lane.
2006-12-30 22:21:56 +01:00
if (defTypeId != newTypeId || deftypmod != newtypmod)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
errmsg("column \"%s\" has a type conflict",
attributeName),
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
errdetail("%s versus %s",
Make backend header files C++ safe This alters various incidental uses of C++ key words to use other similar identifiers, so that a C++ compiler won't choke outright. You still (probably) need extern "C" { }; around the inclusion of backend headers. based on a patch by Kurt Harriman <harriman@acm.org> Also add a script cpluspluscheck to check for C++ compatibility in the future. As of right now, this passes without error for me.
2009-07-16 08:33:46 +02:00
TypeNameToString(def->typeName),
TypeNameToString(newdef->typeName))));
Remove collation information from TypeName, where it does not belong. 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.
2011-03-10 04:38:52 +01:00
defcollid = GetColumnDefCollation(NULL, def, defTypeId);
newcollid = GetColumnDefCollation(NULL, newdef, newTypeId);
Per-column collation support 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
2011-02-08 22:04:18 +01:00
if (defcollid != newcollid)
ereport(ERROR,
(errcode(ERRCODE_COLLATION_MISMATCH),
errmsg("column \"%s\" has a collation conflict",
attributeName),
errdetail("\"%s\" versus \"%s\"",
get_collation_name(defcollid),
get_collation_name(newcollid))));
CREATE LIKE INCLUDING COMMENTS and STORAGE, and INCLUDING ALL shortcut. Itagaki Takahiro.
2009-10-12 21:49:24 +02:00
/* Copy storage parameter */
if (def->storage == 0)
def->storage = newdef->storage;
else if (newdef->storage != 0 && def->storage != newdef->storage)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
errmsg("column \"%s\" has a storage parameter conflict",
attributeName),
errdetail("%s versus %s",
storage_name(def->storage),
storage_name(newdef->storage))));
CREATE LIKE INCLUDING COMMENTS and STORAGE, and INCLUDING ALL shortcut. Itagaki Takahiro.
2009-10-12 21:49:24 +02:00
Replace pg_attribute.attisinherited with attislocal and attinhcount columns, to allow more correct behavior in multiple-inheritance cases. Patch by Alvaro Herrera, review by Tom Lane.
2002-09-22 21:42:52 +02:00
/* Mark the column as locally defined */
def->is_local = true;
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/* Merge of NOT NULL constraints = OR 'em together */
def->is_not_null |= newdef->is_not_null;
/* If new def has a default, override previous default */
if (newdef->raw_default != NULL)
{
def->raw_default = newdef->raw_default;
def->cooked_default = newdef->cooked_default;
}
}
else
{
/*
* No, attach new column to result schema
*/
inhSchema = lappend(inhSchema, newdef);
}
}
schema = inhSchema;
Prevent a backend crash when processing CREATE TABLE commands with more than 65K columns, or when the created table has more than 65K columns due to adding inherited columns from parent relations. Fix a similar crash when processing SELECT queries with more than 65K target list entries. In all three cases we would eventually detect the error and elog, but the check was being made too late.
2004-11-17 00:34:26 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Check that we haven't exceeded the legal # of columns after merging
* in inherited columns.
Prevent a backend crash when processing CREATE TABLE commands with more than 65K columns, or when the created table has more than 65K columns due to adding inherited columns from parent relations. Fix a similar crash when processing SELECT queries with more than 65K target list entries. In all three cases we would eventually detect the error and elog, but the check was being made too late.
2004-11-17 00:34:26 +01:00
*/
if (list_length(schema) > MaxHeapAttributeNumber)
ereport(ERROR,
(errcode(ERRCODE_TOO_MANY_COLUMNS),
errmsg("tables can have at most %d columns",
MaxHeapAttributeNumber)));
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
}
Included all yacc and lex files into the distribution.
2000-01-16 21:05:00 +01:00
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* If we found any conflicting parent default values, check to make sure
* they were overridden by the child.
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
*/
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
if (have_bogus_defaults)
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
{
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
foreach(entry, schema)
Included all yacc and lex files into the distribution.
2000-01-16 21:05:00 +01:00
{
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
ColumnDef *def = lfirst(entry);
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
Change CREATE TABLE so that column default expressions coming from different inheritance parent tables are compared using equal(), instead of doing strcmp() on the nodeToString representation. The old implementation was always a tad cheesy, and it finally fails completely as of 8.4, now that the node tree might contain syntax location information. equal() knows it's supposed to ignore those fields, but strcmp() hardly can. Per recent report from Scott Ribe.
2009-10-06 02:55:26 +02:00
if (def->cooked_default == &bogus_marker)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_INVALID_COLUMN_DEFINITION),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("column \"%s\" inherits conflicting default values",
def->colname),
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
errhint("To resolve the conflict, specify a default explicitly.")));
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
}
}
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*supOids = parentOids;
*supconstr = constraints;
Upgrade ALTER TABLE DROP COLUMN so that it can drop an OID column, and remove separate implementation of ALTER TABLE SET WITHOUT OIDS in favor of doing a regular DROP. Also, cause CREATE TABLE to account completely correctly for the inheritance status of the OID column. This fixes problems with dropping OID columns that have dependencies, as noted by Christopher Kings-Lynne, as well as making sure that you can't drop an OID column that was inherited from a parent.
2004-03-23 20:35:17 +01:00
*supOidCount = parentsWithOids;
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
return schema;
}
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
Code review for LIKE INCLUDING CONSTRAINTS patch --- improve comments, don't cheat on the raw-vs-cooked status of a constraint.
2006-10-11 18:42:59 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
* MergeCheckConstraint
* Try to merge an inherited CHECK constraint with previous ones
*
* If we inherit identically-named constraints from multiple parents, we must
* merge them, or throw an error if they don't have identical definitions.
*
* constraints is a list of CookedConstraint structs for previous constraints.
*
* Returns TRUE if merged (constraint is a duplicate), or FALSE if it's
* got a so-far-unique name, or throws error if conflict.
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*/
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
static bool
MergeCheckConstraint(List *constraints, char *name, Node *expr)
Add INCLUDING CONSTRAINTS to CREATE TABLE LIKE. Greg Stark
2006-06-27 05:43:20 +02:00
{
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
ListCell *lc;
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
foreach(lc, constraints)
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
{
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
CookedConstraint *ccon = (CookedConstraint *) lfirst(lc);
Assert(ccon->contype == CONSTR_CHECK);
/* Non-matching names never conflict */
if (strcmp(ccon->name, name) != 0)
Add INCLUDING CONSTRAINTS to CREATE TABLE LIKE. Greg Stark
2006-06-27 05:43:20 +02:00
continue;
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
if (equal(expr, ccon->expr))
{
/* OK to merge */
ccon->inhcount++;
return true;
}
Code review for LIKE INCLUDING CONSTRAINTS patch --- improve comments, don't cheat on the raw-vs-cooked status of a constraint.
2006-10-11 18:42:59 +02:00
ereport(ERROR,
(errcode(ERRCODE_DUPLICATE_OBJECT),
Clarify some error messages about duplicate things.
2007-06-04 00:16:03 +02:00
errmsg("check constraint name \"%s\" appears multiple times but with different expressions",
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
name)));
Add INCLUDING CONSTRAINTS to CREATE TABLE LIKE. Greg Stark
2006-06-27 05:43:20 +02:00
}
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
return false;
Add INCLUDING CONSTRAINTS to CREATE TABLE LIKE. Greg Stark
2006-06-27 05:43:20 +02:00
}
Code review for LIKE INCLUDING CONSTRAINTS patch --- improve comments, don't cheat on the raw-vs-cooked status of a constraint.
2006-10-11 18:42:59 +02:00
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
/*
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
* StoreCatalogInheritance
* Updates the system catalogs with proper inheritance information.
*
Create a distinction between Lists of integers and Lists of OIDs, to get rid of the assumption that sizeof(Oid)==sizeof(int). This is one small step towards someday supporting 8-byte OIDs. For the moment, it doesn't do much except get rid of a lot of unsightly casts.
2003-02-09 07:56:28 +01:00
* supers is a list of the OIDs of the new relation's direct ancestors.
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
*/
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
static void
StoreCatalogInheritance(Oid relationId, List *supers)
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
{
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
Relation relation;
int16 seqNumber;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *entry;
pg_type has a typnamespace column; system now supports creating types in different namespaces. Also, cleanup work on relation namespace support: drop, alter, rename commands work for tables in non-default namespaces.
2002-03-29 20:06:29 +01:00
Add mention of function CREATE INDEX usage.
2002-04-12 01:20:04 +02:00
/*
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
* sanity checks
Add mention of function CREATE INDEX usage.
2002-04-12 01:20:04 +02:00
*/
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
AssertArg(OidIsValid(relationId));
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
if (supers == NIL)
return;
Change made to elog: o Change all current CVS messages of NOTICE to WARNING. We were going to do this just before 7.3 beta but it has to be done now, as you will see below. o Change current INFO messages that should be controlled by client_min_messages to NOTICE. o Force remaining INFO messages, like from EXPLAIN, VACUUM VERBOSE, etc. to always go to the client. o Remove INFO from the client_min_messages options and add NOTICE. Seems we do need three non-ERROR elog levels to handle the various behaviors we need for these messages. Regression passed.
2002-03-06 07:10:59 +01:00
I attach a version of my toast-slicing patch, against current CVS (current as of a few hours ago.) This patch: 1. Adds PG_GETARG_xxx_P_SLICE() macros and associated support routines. 2. Adds routines in src/backend/access/tuptoaster.c for fetching only necessary chunks of a toasted value. (Modelled on latest changes to assume chunks are returned in order). 3. Amends text_substr and bytea_substr to use new methods. It now handles multibyte cases -and should still lead to a performance improvement in the multibyte case where the substring is near the beginning of the string. 4. Added new command: ALTER TABLE tabname ALTER COLUMN colname SET STORAGE {PLAIN | EXTERNAL | EXTENDED | MAIN} to parser and documented in alter-table.sgml. (NB I used ColId as the item type for the storage mode string, rather than a new production - I hope this makes sense!). All this does is sets attstorage for the specified column. 4. AlterTableAlterColumnStatistics is now AlterTableAlterColumnFlags and handles both statistics and storage (it uses the subtype code to distinguish). The previous version of my patch also re-arranged other code in backend/commands/command.c but I have dropped that from this patch.(I plan to return to it separately). 5. Documented new macros (and also the PG_GETARG_xxx_P_COPY macros) in xfunc.sgml. ref/alter_table.sgml also contains documentation for ALTER COLUMN SET STORAGE. John Gray
2002-03-05 06:33:31 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Store INHERITS information in pg_inherits using direct ancestors only.
* Also enter dependencies on the direct ancestors, and make sure they are
* marked with relhassubclass = true.
Adjust setRelhassubclassInRelation() to not perform actual heap_update when the pg_class.relhassubclass value is already correct. This should avoid most cases of the 'tuple concurrently updated' problem that Robert Creager recently complained about. Also remove a bunch of dead code in StoreCatalogInheritance() --- it was still computing the complete list of direct and indirect inheritance ancestors, though that list has not been needed since we got rid of the pg_ipl catalog.
2003-10-13 22:02:52 +02:00
*
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
* (Once upon a time, both direct and indirect ancestors were found here
* and then entered into pg_ipl. Since that catalog doesn't exist
* anymore, there's no need to look for indirect ancestors.)
I attach a version of my toast-slicing patch, against current CVS (current as of a few hours ago.) This patch: 1. Adds PG_GETARG_xxx_P_SLICE() macros and associated support routines. 2. Adds routines in src/backend/access/tuptoaster.c for fetching only necessary chunks of a toasted value. (Modelled on latest changes to assume chunks are returned in order). 3. Amends text_substr and bytea_substr to use new methods. It now handles multibyte cases -and should still lead to a performance improvement in the multibyte case where the substring is near the beginning of the string. 4. Added new command: ALTER TABLE tabname ALTER COLUMN colname SET STORAGE {PLAIN | EXTERNAL | EXTENDED | MAIN} to parser and documented in alter-table.sgml. (NB I used ColId as the item type for the storage mode string, rather than a new production - I hope this makes sense!). All this does is sets attstorage for the specified column. 4. AlterTableAlterColumnStatistics is now AlterTableAlterColumnFlags and handles both statistics and storage (it uses the subtype code to distinguish). The previous version of my patch also re-arranged other code in backend/commands/command.c but I have dropped that from this patch.(I plan to return to it separately). 5. Documented new macros (and also the PG_GETARG_xxx_P_COPY macros) in xfunc.sgml. ref/alter_table.sgml also contains documentation for ALTER COLUMN SET STORAGE. John Gray
2002-03-05 06:33:31 +01:00
*/
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
relation = heap_open(InheritsRelationId, RowExclusiveLock);
Change made to elog: o Change all current CVS messages of NOTICE to WARNING. We were going to do this just before 7.3 beta but it has to be done now, as you will see below. o Change current INFO messages that should be controlled by client_min_messages to NOTICE. o Force remaining INFO messages, like from EXPLAIN, VACUUM VERBOSE, etc. to always go to the client. o Remove INFO from the client_min_messages options and add NOTICE. Seems we do need three non-ERROR elog levels to handle the various behaviors we need for these messages. Regression passed.
2002-03-06 07:10:59 +01:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
seqNumber = 1;
foreach(entry, supers)
I attach a version of my toast-slicing patch, against current CVS (current as of a few hours ago.) This patch: 1. Adds PG_GETARG_xxx_P_SLICE() macros and associated support routines. 2. Adds routines in src/backend/access/tuptoaster.c for fetching only necessary chunks of a toasted value. (Modelled on latest changes to assume chunks are returned in order). 3. Amends text_substr and bytea_substr to use new methods. It now handles multibyte cases -and should still lead to a performance improvement in the multibyte case where the substring is near the beginning of the string. 4. Added new command: ALTER TABLE tabname ALTER COLUMN colname SET STORAGE {PLAIN | EXTERNAL | EXTENDED | MAIN} to parser and documented in alter-table.sgml. (NB I used ColId as the item type for the storage mode string, rather than a new production - I hope this makes sense!). All this does is sets attstorage for the specified column. 4. AlterTableAlterColumnStatistics is now AlterTableAlterColumnFlags and handles both statistics and storage (it uses the subtype code to distinguish). The previous version of my patch also re-arranged other code in backend/commands/command.c but I have dropped that from this patch.(I plan to return to it separately). 5. Documented new macros (and also the PG_GETARG_xxx_P_COPY macros) in xfunc.sgml. ref/alter_table.sgml also contains documentation for ALTER COLUMN SET STORAGE. John Gray
2002-03-05 06:33:31 +01:00
{
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
Oid parentOid = lfirst_oid(entry);
StoreCatalogInheritance1(relationId, parentOid, seqNumber, relation);
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
seqNumber++;
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
}
heap_close(relation, RowExclusiveLock);
}
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
/*
* Make catalog entries showing relationId as being an inheritance child
* of parentOid. inhRelation is the already-opened pg_inherits catalog.
*/
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
static void
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
StoreCatalogInheritance1(Oid relationId, Oid parentOid,
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
int16 seqNumber, Relation inhRelation)
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
{
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
TupleDesc desc = RelationGetDescr(inhRelation);
Add an index on pg_inherits.inhparent, and use it to avoid seqscans in find_inheritance_children(). This is a complete no-op in databases without any inheritance. In databases where there are just a few entries in pg_inherits, it could conceivably be a small loss. However, in databases with many inheritance parents, it can be a big win.
2009-12-29 23:00:14 +01:00
Datum values[Natts_pg_inherits];
bool nulls[Natts_pg_inherits];
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
ObjectAddress childobject,
parentobject;
HeapTuple tuple;
Change made to elog: o Change all current CVS messages of NOTICE to WARNING. We were going to do this just before 7.3 beta but it has to be done now, as you will see below. o Change current INFO messages that should be controlled by client_min_messages to NOTICE. o Force remaining INFO messages, like from EXPLAIN, VACUUM VERBOSE, etc. to always go to the client. o Remove INFO from the client_min_messages options and add NOTICE. Seems we do need three non-ERROR elog levels to handle the various behaviors we need for these messages. Regression passed.
2002-03-06 07:10:59 +01:00
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
/*
* Make the pg_inherits entry
*/
Add an index on pg_inherits.inhparent, and use it to avoid seqscans in find_inheritance_children(). This is a complete no-op in databases without any inheritance. In databases where there are just a few entries in pg_inherits, it could conceivably be a small loss. However, in databases with many inheritance parents, it can be a big win.
2009-12-29 23:00:14 +01:00
values[Anum_pg_inherits_inhrelid - 1] = ObjectIdGetDatum(relationId);
values[Anum_pg_inherits_inhparent - 1] = ObjectIdGetDatum(parentOid);
values[Anum_pg_inherits_inhseqno - 1] = Int16GetDatum(seqNumber);
Fix incorrect Assert; install a more trustworthy check on whether ALTER COLUMN SET STORAGE should be allowed.
2002-04-22 23:46:11 +02:00
Add an index on pg_inherits.inhparent, and use it to avoid seqscans in find_inheritance_children(). This is a complete no-op in databases without any inheritance. In databases where there are just a few entries in pg_inherits, it could conceivably be a small loss. However, in databases with many inheritance parents, it can be a big win.
2009-12-29 23:00:14 +01:00
memset(nulls, 0, sizeof(nulls));
I attach a version of my toast-slicing patch, against current CVS (current as of a few hours ago.) This patch: 1. Adds PG_GETARG_xxx_P_SLICE() macros and associated support routines. 2. Adds routines in src/backend/access/tuptoaster.c for fetching only necessary chunks of a toasted value. (Modelled on latest changes to assume chunks are returned in order). 3. Amends text_substr and bytea_substr to use new methods. It now handles multibyte cases -and should still lead to a performance improvement in the multibyte case where the substring is near the beginning of the string. 4. Added new command: ALTER TABLE tabname ALTER COLUMN colname SET STORAGE {PLAIN | EXTERNAL | EXTENDED | MAIN} to parser and documented in alter-table.sgml. (NB I used ColId as the item type for the storage mode string, rather than a new production - I hope this makes sense!). All this does is sets attstorage for the specified column. 4. AlterTableAlterColumnStatistics is now AlterTableAlterColumnFlags and handles both statistics and storage (it uses the subtype code to distinguish). The previous version of my patch also re-arranged other code in backend/commands/command.c but I have dropped that from this patch.(I plan to return to it separately). 5. Documented new macros (and also the PG_GETARG_xxx_P_COPY macros) in xfunc.sgml. ref/alter_table.sgml also contains documentation for ALTER COLUMN SET STORAGE. John Gray
2002-03-05 06:33:31 +01:00
Add an index on pg_inherits.inhparent, and use it to avoid seqscans in find_inheritance_children(). This is a complete no-op in databases without any inheritance. In databases where there are just a few entries in pg_inherits, it could conceivably be a small loss. However, in databases with many inheritance parents, it can be a big win.
2009-12-29 23:00:14 +01:00
tuple = heap_form_tuple(desc, values, nulls);
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
simple_heap_insert(inhRelation, tuple);
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
CatalogUpdateIndexes(inhRelation, tuple);
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
heap_freetuple(tuple);
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
/*
* Store a dependency too
*/
parentobject.classId = RelationRelationId;
parentobject.objectId = parentOid;
parentobject.objectSubId = 0;
childobject.classId = RelationRelationId;
childobject.objectId = relationId;
childobject.objectSubId = 0;
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
recordDependencyOn(&childobject, &parentobject, DEPENDENCY_NORMAL);
Adjust setRelhassubclassInRelation() to not perform actual heap_update when the pg_class.relhassubclass value is already correct. This should avoid most cases of the 'tuple concurrently updated' problem that Robert Creager recently complained about. Also remove a bunch of dead code in StoreCatalogInheritance() --- it was still computing the complete list of direct and indirect inheritance ancestors, though that list has not been needed since we got rid of the pg_ipl catalog.
2003-10-13 22:02:52 +02:00
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
/*
* Post creation hook of this inheritance. Since object_access_hook
* doesn't take multiple object identifiers, we relay oid of parent
* relation using auxiliary_id argument.
*/
InvokeObjectPostAlterHookArg(InheritsRelationId,
relationId, 0,
parentOid, false);
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
/*
* Mark the parent as having subclasses.
*/
Teach ANALYZE to clear pg_class.relhassubclass when appropriate. 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.
2011-09-02 20:29:31 +02:00
SetRelationHasSubclass(parentOid, true);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
}
Included all yacc and lex files into the distribution.
2000-01-16 21:05:00 +01:00
/*
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
* Look for an existing schema entry with the given name.
*
* Returns the index (starting with 1) if attribute already exists in schema,
* 0 if it doesn't.
Included all yacc and lex files into the distribution.
2000-01-16 21:05:00 +01:00
*/
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
static int
findAttrByName(const char *attributeName, List *schema)
Included all yacc and lex files into the distribution.
2000-01-16 21:05:00 +01:00
{
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *s;
int i = 1;
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
foreach(s, schema)
{
ColumnDef *def = lfirst(s);
if (strcmp(attributeName, def->colname) == 0)
return i;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
i++;
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
}
return 0;
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
SET TRANSACTION ISOLATION LEVEL ... LOCK TABLE IN ... MODE ...implemented
1998-12-18 10:10:39 +01:00
Teach ANALYZE to clear pg_class.relhassubclass when appropriate. 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.
2011-09-02 20:29:31 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
Teach ANALYZE to clear pg_class.relhassubclass when appropriate. 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.
2011-09-02 20:29:31 +02:00
* SetRelationHasSubclass
* Set the value of the relation's relhassubclass field in pg_class.
*
* NOTE: caller must be holding an appropriate lock on the relation.
* ShareUpdateExclusiveLock is sufficient.
*
* NOTE: an important side-effect of this operation is that an SI invalidation
* message is sent out to all backends --- including me --- causing plans
* referencing the relation to be rebuilt with the new list of children.
* This must happen even if we find that no change is needed in the pg_class
* row.
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*/
Teach ANALYZE to clear pg_class.relhassubclass when appropriate. 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.
2011-09-02 20:29:31 +02:00
void
SetRelationHasSubclass(Oid relationId, bool relhassubclass)
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
{
Relation relationRelation;
HeapTuple tuple;
Adjust setRelhassubclassInRelation() to not perform actual heap_update when the pg_class.relhassubclass value is already correct. This should avoid most cases of the 'tuple concurrently updated' problem that Robert Creager recently complained about. Also remove a bunch of dead code in StoreCatalogInheritance() --- it was still computing the complete list of direct and indirect inheritance ancestors, though that list has not been needed since we got rid of the pg_ipl catalog.
2003-10-13 22:02:52 +02:00
Form_pg_class classtuple;
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
* Fetch a modifiable copy of the tuple, modify it, update pg_class.
*/
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
relationRelation = heap_open(RelationRelationId, RowExclusiveLock);
Wrap calls to SearchSysCache and related functions using macros. The purpose of this change is to eliminate the need for every caller of SearchSysCache, SearchSysCacheCopy, SearchSysCacheExists, GetSysCacheOid, and SearchSysCacheList to know the maximum number of allowable keys for a syscache entry (currently 4). This will make it far easier to increase the maximum number of keys in a future release should we choose to do so, and it makes the code shorter, too. Design and review by Tom Lane.
2010-02-14 19:42:19 +01:00
tuple = SearchSysCacheCopy1(RELOID, ObjectIdGetDatum(relationId));
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
if (!HeapTupleIsValid(tuple))
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
elog(ERROR, "cache lookup failed for relation %u", relationId);
Adjust setRelhassubclassInRelation() to not perform actual heap_update when the pg_class.relhassubclass value is already correct. This should avoid most cases of the 'tuple concurrently updated' problem that Robert Creager recently complained about. Also remove a bunch of dead code in StoreCatalogInheritance() --- it was still computing the complete list of direct and indirect inheritance ancestors, though that list has not been needed since we got rid of the pg_ipl catalog.
2003-10-13 22:02:52 +02:00
classtuple = (Form_pg_class) GETSTRUCT(tuple);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
Adjust setRelhassubclassInRelation() to not perform actual heap_update when the pg_class.relhassubclass value is already correct. This should avoid most cases of the 'tuple concurrently updated' problem that Robert Creager recently complained about. Also remove a bunch of dead code in StoreCatalogInheritance() --- it was still computing the complete list of direct and indirect inheritance ancestors, though that list has not been needed since we got rid of the pg_ipl catalog.
2003-10-13 22:02:52 +02:00
if (classtuple->relhassubclass != relhassubclass)
{
classtuple->relhassubclass = relhassubclass;
simple_heap_update(relationRelation, &tuple->t_self, tuple);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
Adjust setRelhassubclassInRelation() to not perform actual heap_update when the pg_class.relhassubclass value is already correct. This should avoid most cases of the 'tuple concurrently updated' problem that Robert Creager recently complained about. Also remove a bunch of dead code in StoreCatalogInheritance() --- it was still computing the complete list of direct and indirect inheritance ancestors, though that list has not been needed since we got rid of the pg_ipl catalog.
2003-10-13 22:02:52 +02:00
/* keep the catalog indexes up to date */
CatalogUpdateIndexes(relationRelation, tuple);
}
else
{
/* no need to change tuple, but force relcache rebuild anyway */
Restructure smgr API as per recent proposal. smgr no longer depends on the relcache, and so the notion of 'blind write' is gone. This should improve efficiency in bgwriter and background checkpoint processes. Internal restructuring in md.c to remove the not-very-useful array of MdfdVec objects --- might as well just use pointers. Also remove the long-dead 'persistent main memory' storage manager (mm.c), since it seems quite unlikely to ever get resurrected.
2004-02-10 02:55:27 +01:00
CacheInvalidateRelcacheByTuple(tuple);
Adjust setRelhassubclassInRelation() to not perform actual heap_update when the pg_class.relhassubclass value is already correct. This should avoid most cases of the 'tuple concurrently updated' problem that Robert Creager recently complained about. Also remove a bunch of dead code in StoreCatalogInheritance() --- it was still computing the complete list of direct and indirect inheritance ancestors, though that list has not been needed since we got rid of the pg_ipl catalog.
2003-10-13 22:02:52 +02:00
}
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
heap_freetuple(tuple);
heap_close(relationRelation, RowExclusiveLock);
}
Included all yacc and lex files into the distribution.
2000-01-16 21:05:00 +01:00
added ALTER TABLE DROP COLUMN, early version
2000-01-22 15:20:56 +01:00
/*
Improve behavior of concurrent rename statements. Previously, renaming a table, sequence, view, index, foreign table, column, or trigger checked permissions before locking the object, which meant that if permissions were revoked during the lock wait, we would still allow the operation. Similarly, if the original object is dropped and a new one with the same name is created, the operation will be allowed if we had permissions on the old object; the permissions on the new object don't matter. All this is now fixed. Along the way, attempting to rename a trigger on a foreign table now gives the same error message as trying to create one there in the first place (i.e. that it's not a table or view) rather than simply stating that no trigger by that name exists. Patch by me; review by Noah Misch.
2011-12-16 00:51:46 +01:00
* renameatt_check - basic sanity checks before attribute rename
added ALTER TABLE DROP COLUMN, early version
2000-01-22 15:20:56 +01:00
*/
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
static void
Improve behavior of concurrent rename statements. Previously, renaming a table, sequence, view, index, foreign table, column, or trigger checked permissions before locking the object, which meant that if permissions were revoked during the lock wait, we would still allow the operation. Similarly, if the original object is dropped and a new one with the same name is created, the operation will be allowed if we had permissions on the old object; the permissions on the new object don't matter. All this is now fixed. Along the way, attempting to rename a trigger on a foreign table now gives the same error message as trying to create one there in the first place (i.e. that it's not a table or view) rather than simply stating that no trigger by that name exists. Patch by me; review by Noah Misch.
2011-12-16 00:51:46 +01:00
renameatt_check(Oid myrelid, Form_pg_class classform, bool recursing)
Included all yacc and lex files into the distribution.
2000-01-16 21:05:00 +01:00
{
Improve behavior of concurrent rename statements. Previously, renaming a table, sequence, view, index, foreign table, column, or trigger checked permissions before locking the object, which meant that if permissions were revoked during the lock wait, we would still allow the operation. Similarly, if the original object is dropped and a new one with the same name is created, the operation will be allowed if we had permissions on the old object; the permissions on the new object don't matter. All this is now fixed. Along the way, attempting to rename a trigger on a foreign table now gives the same error message as trying to create one there in the first place (i.e. that it's not a table or view) rather than simply stating that no trigger by that name exists. Patch by me; review by Noah Misch.
2011-12-16 00:51:46 +01:00
char relkind = classform->relkind;
pg_type has a typnamespace column; system now supports creating types in different namespaces. Also, cleanup work on relation namespace support: drop, alter, rename commands work for tables in non-default namespaces.
2002-03-29 20:06:29 +01:00
Improve behavior of concurrent rename statements. Previously, renaming a table, sequence, view, index, foreign table, column, or trigger checked permissions before locking the object, which meant that if permissions were revoked during the lock wait, we would still allow the operation. Similarly, if the original object is dropped and a new one with the same name is created, the operation will be allowed if we had permissions on the old object; the permissions on the new object don't matter. All this is now fixed. Along the way, attempting to rename a trigger on a foreign table now gives the same error message as trying to create one there in the first place (i.e. that it's not a table or view) rather than simply stating that no trigger by that name exists. Patch by me; review by Noah Misch.
2011-12-16 00:51:46 +01:00
if (classform->reloftype && !recursing)
Type table feature This adds the CREATE TABLE name OF type command, per SQL standard.
2010-01-29 00:21:13 +01:00
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("cannot rename column of typed table")));
Forbid renaming columns of objects whose column names are system-generated. KaiGai Kohei, with adjustments to the comments.
2010-03-20 01:43:42 +01:00
/*
* Renaming the columns of sequences or toast tables doesn't actually
* break anything from the system's point of view, since internal
pgindent run for 9.0, second run
2010-07-06 21:19:02 +02:00
* references are by attnum. But it doesn't seem right to allow users to
* change names that are hardcoded into the system, hence the following
Forbid renaming columns of objects whose column names are system-generated. KaiGai Kohei, with adjustments to the comments.
2010-03-20 01:43:42 +01:00
* restriction.
*/
if (relkind != RELKIND_RELATION &&
relkind != RELKIND_VIEW &&
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
relkind != RELKIND_MATVIEW &&
Forbid renaming columns of objects whose column names are system-generated. KaiGai Kohei, with adjustments to the comments.
2010-03-20 01:43:42 +01:00
relkind != RELKIND_COMPOSITE_TYPE &&
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
relkind != RELKIND_INDEX &&
relkind != RELKIND_FOREIGN_TABLE)
Forbid renaming columns of objects whose column names are system-generated. KaiGai Kohei, with adjustments to the comments.
2010-03-20 01:43:42 +01:00
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
errmsg("\"%s\" is not a table, view, materialized view, composite type, index, or foreign table",
Improve behavior of concurrent rename statements. Previously, renaming a table, sequence, view, index, foreign table, column, or trigger checked permissions before locking the object, which meant that if permissions were revoked during the lock wait, we would still allow the operation. Similarly, if the original object is dropped and a new one with the same name is created, the operation will be allowed if we had permissions on the old object; the permissions on the new object don't matter. All this is now fixed. Along the way, attempting to rename a trigger on a foreign table now gives the same error message as trying to create one there in the first place (i.e. that it's not a table or view) rather than simply stating that no trigger by that name exists. Patch by me; review by Noah Misch.
2011-12-16 00:51:46 +01:00
NameStr(classform->relname))));
Forbid renaming columns of objects whose column names are system-generated. KaiGai Kohei, with adjustments to the comments.
2010-03-20 01:43:42 +01:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
Fix incorrect comment about permissions checking being done in utility.c. Noted while reviewing a patch from KaiGai Kohei.
2010-03-10 20:48:39 +01:00
* permissions checking. only the owner of a class can change its schema.
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*/
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
if (!pg_class_ownercheck(myrelid, GetUserId()))
Adjust 'permission denied' messages to be more useful and consistent.
2003-08-01 02:15:26 +02:00
aclcheck_error(ACLCHECK_NOT_OWNER, ACL_KIND_CLASS,
Improve behavior of concurrent rename statements. Previously, renaming a table, sequence, view, index, foreign table, column, or trigger checked permissions before locking the object, which meant that if permissions were revoked during the lock wait, we would still allow the operation. Similarly, if the original object is dropped and a new one with the same name is created, the operation will be allowed if we had permissions on the old object; the permissions on the new object don't matter. All this is now fixed. Along the way, attempting to rename a trigger on a foreign table now gives the same error message as trying to create one there in the first place (i.e. that it's not a table or view) rather than simply stating that no trigger by that name exists. Patch by me; review by Noah Misch.
2011-12-16 00:51:46 +01:00
NameStr(classform->relname));
if (!allowSystemTableMods && IsSystemClass(classform))
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
Adjust 'permission denied' messages to be more useful and consistent.
2003-08-01 02:15:26 +02:00
errmsg("permission denied: \"%s\" is a system catalog",
Improve behavior of concurrent rename statements. Previously, renaming a table, sequence, view, index, foreign table, column, or trigger checked permissions before locking the object, which meant that if permissions were revoked during the lock wait, we would still allow the operation. Similarly, if the original object is dropped and a new one with the same name is created, the operation will be allowed if we had permissions on the old object; the permissions on the new object don't matter. All this is now fixed. Along the way, attempting to rename a trigger on a foreign table now gives the same error message as trying to create one there in the first place (i.e. that it's not a table or view) rather than simply stating that no trigger by that name exists. Patch by me; review by Noah Misch.
2011-12-16 00:51:46 +01:00
NameStr(classform->relname))));
}
/*
* renameatt_internal - workhorse for renameatt
*/
static void
renameatt_internal(Oid myrelid,
const char *oldattname,
const char *newattname,
bool recurse,
bool recursing,
int expected_parents,
DropBehavior behavior)
{
Relation targetrelation;
Relation attrelation;
HeapTuple atttup;
pgindent run for release 9.3 This is the first run of the Perl-based pgindent script. Also update pgindent instructions.
2013-05-29 22:58:43 +02:00
Form_pg_attribute attform;
Improve behavior of concurrent rename statements. Previously, renaming a table, sequence, view, index, foreign table, column, or trigger checked permissions before locking the object, which meant that if permissions were revoked during the lock wait, we would still allow the operation. Similarly, if the original object is dropped and a new one with the same name is created, the operation will be allowed if we had permissions on the old object; the permissions on the new object don't matter. All this is now fixed. Along the way, attempting to rename a trigger on a foreign table now gives the same error message as trying to create one there in the first place (i.e. that it's not a table or view) rather than simply stating that no trigger by that name exists. Patch by me; review by Noah Misch.
2011-12-16 00:51:46 +01:00
int attnum;
/*
* Grab an exclusive lock on the target table, which we will NOT release
* until end of transaction.
*/
targetrelation = relation_open(myrelid, AccessExclusiveLock);
renameatt_check(myrelid, RelationGetForm(targetrelation), recursing);
Break transformCreateStmt() into multiple routines and make transformAlterStmt() use these routines, instead of having lots of duplicate (not to mention should-have-been-duplicate) code. Adding a column with a CHECK constraint actually works now, and the tests to reject unsupported DEFAULT and NOT NULL clauses actually fire now. ALTER TABLE ADD PRIMARY KEY works, modulo having to have created the column(s) NOT NULL already.
2001-10-12 02:07:15 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
* if the 'recurse' flag is set then we are supposed to rename this
* attribute in all classes that inherit from 'relname' (as well as in
* 'relname').
*
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
* any permissions or problems with duplicate attributes will cause the
* whole transaction to abort, which is what we want -- all or nothing.
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*/
if (recurse)
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
{
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
List *child_oids,
*child_numparents;
ListCell *lo,
*li;
Break transformCreateStmt() into multiple routines and make transformAlterStmt() use these routines, instead of having lots of duplicate (not to mention should-have-been-duplicate) code. Adding a column with a CHECK constraint actually works now, and the tests to reject unsupported DEFAULT and NOT NULL clauses actually fire now. ALTER TABLE ADD PRIMARY KEY works, modulo having to have created the column(s) NOT NULL already.
2001-10-12 02:07:15 +02:00
Tighten integrity checks on ALTER TABLE ... ALTER COLUMN ... RENAME. When a column is renamed, we recursively rename the same column in all descendent tables. But if one of those tables also inherits that column from a table outside the inheritance hierarchy rooted at the named table, we must throw an error. The previous coding correctly prohibited the rename when the parent had inherited the column from elsewhere, but overlooked the case where the parent was OK but a child table also inherited the same column from a second, unrelated parent. For now, not backpatched due to lack of complaints from the field. KaiGai Kohei, with further changes by me. Reviewed by Bernd Helme and Tom Lane.
2010-02-01 20:28:56 +01:00
/*
* we need the number of parents for each child so that the recursive
* calls to renameatt() can determine whether there are any parents
* outside the inheritance hierarchy being processed.
*/
child_oids = find_all_inheritors(myrelid, AccessExclusiveLock,
&child_numparents);
Break transformCreateStmt() into multiple routines and make transformAlterStmt() use these routines, instead of having lots of duplicate (not to mention should-have-been-duplicate) code. Adding a column with a CHECK constraint actually works now, and the tests to reject unsupported DEFAULT and NOT NULL clauses actually fire now. ALTER TABLE ADD PRIMARY KEY works, modulo having to have created the column(s) NOT NULL already.
2001-10-12 02:07:15 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* find_all_inheritors does the recursive search of the inheritance
* hierarchy, so all we have to do is process all of the relids in the
* list that it returns.
Break transformCreateStmt() into multiple routines and make transformAlterStmt() use these routines, instead of having lots of duplicate (not to mention should-have-been-duplicate) code. Adding a column with a CHECK constraint actually works now, and the tests to reject unsupported DEFAULT and NOT NULL clauses actually fire now. ALTER TABLE ADD PRIMARY KEY works, modulo having to have created the column(s) NOT NULL already.
2001-10-12 02:07:15 +02:00
*/
Tighten integrity checks on ALTER TABLE ... ALTER COLUMN ... RENAME. When a column is renamed, we recursively rename the same column in all descendent tables. But if one of those tables also inherits that column from a table outside the inheritance hierarchy rooted at the named table, we must throw an error. The previous coding correctly prohibited the rename when the parent had inherited the column from elsewhere, but overlooked the case where the parent was OK but a child table also inherited the same column from a second, unrelated parent. For now, not backpatched due to lack of complaints from the field. KaiGai Kohei, with further changes by me. Reviewed by Bernd Helme and Tom Lane.
2010-02-01 20:28:56 +01:00
forboth(lo, child_oids, li, child_numparents)
Break transformCreateStmt() into multiple routines and make transformAlterStmt() use these routines, instead of having lots of duplicate (not to mention should-have-been-duplicate) code. Adding a column with a CHECK constraint actually works now, and the tests to reject unsupported DEFAULT and NOT NULL clauses actually fire now. ALTER TABLE ADD PRIMARY KEY works, modulo having to have created the column(s) NOT NULL already.
2001-10-12 02:07:15 +02:00
{
Tighten integrity checks on ALTER TABLE ... ALTER COLUMN ... RENAME. When a column is renamed, we recursively rename the same column in all descendent tables. But if one of those tables also inherits that column from a table outside the inheritance hierarchy rooted at the named table, we must throw an error. The previous coding correctly prohibited the rename when the parent had inherited the column from elsewhere, but overlooked the case where the parent was OK but a child table also inherited the same column from a second, unrelated parent. For now, not backpatched due to lack of complaints from the field. KaiGai Kohei, with further changes by me. Reviewed by Bernd Helme and Tom Lane.
2010-02-01 20:28:56 +01:00
Oid childrelid = lfirst_oid(lo);
int numparents = lfirst_int(li);
Break transformCreateStmt() into multiple routines and make transformAlterStmt() use these routines, instead of having lots of duplicate (not to mention should-have-been-duplicate) code. Adding a column with a CHECK constraint actually works now, and the tests to reject unsupported DEFAULT and NOT NULL clauses actually fire now. ALTER TABLE ADD PRIMARY KEY works, modulo having to have created the column(s) NOT NULL already.
2001-10-12 02:07:15 +02:00
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
if (childrelid == myrelid)
Break transformCreateStmt() into multiple routines and make transformAlterStmt() use these routines, instead of having lots of duplicate (not to mention should-have-been-duplicate) code. Adding a column with a CHECK constraint actually works now, and the tests to reject unsupported DEFAULT and NOT NULL clauses actually fire now. ALTER TABLE ADD PRIMARY KEY works, modulo having to have created the column(s) NOT NULL already.
2001-10-12 02:07:15 +02:00
continue;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* note we need not recurse again */
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
renameatt_internal(childrelid, oldattname, newattname, false, true, numparents, behavior);
Break transformCreateStmt() into multiple routines and make transformAlterStmt() use these routines, instead of having lots of duplicate (not to mention should-have-been-duplicate) code. Adding a column with a CHECK constraint actually works now, and the tests to reject unsupported DEFAULT and NOT NULL clauses actually fire now. ALTER TABLE ADD PRIMARY KEY works, modulo having to have created the column(s) NOT NULL already.
2001-10-12 02:07:15 +02:00
}
}
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
else
{
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* If we are told not to recurse, there had better not be any child
* tables; else the rename would put them out of step.
Tighten integrity checks on ALTER TABLE ... ALTER COLUMN ... RENAME. When a column is renamed, we recursively rename the same column in all descendent tables. But if one of those tables also inherits that column from a table outside the inheritance hierarchy rooted at the named table, we must throw an error. The previous coding correctly prohibited the rename when the parent had inherited the column from elsewhere, but overlooked the case where the parent was OK but a child table also inherited the same column from a second, unrelated parent. For now, not backpatched due to lack of complaints from the field. KaiGai Kohei, with further changes by me. Reviewed by Bernd Helme and Tom Lane.
2010-02-01 20:28:56 +01:00
*
* expected_parents will only be 0 if we are not already recursing.
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
*/
Tighten integrity checks on ALTER TABLE ... ALTER COLUMN ... RENAME. When a column is renamed, we recursively rename the same column in all descendent tables. But if one of those tables also inherits that column from a table outside the inheritance hierarchy rooted at the named table, we must throw an error. The previous coding correctly prohibited the rename when the parent had inherited the column from elsewhere, but overlooked the case where the parent was OK but a child table also inherited the same column from a second, unrelated parent. For now, not backpatched due to lack of complaints from the field. KaiGai Kohei, with further changes by me. Reviewed by Bernd Helme and Tom Lane.
2010-02-01 20:28:56 +01:00
if (expected_parents == 0 &&
Modify find_inheritance_children() and find_all_inheritors() to add the ability to lock relations as they scan pg_inherits, and to ignore any relations that have disappeared by the time we get lock on them. This makes uses of these functions safe against concurrent DROP operations on child tables: we will effectively ignore any just-dropped child, rather than possibly throwing an error as in recent bug report from Thomas Johansson (and similar past complaints). The behavior should not change otherwise, since the code was acquiring those same locks anyway, just a little bit later. An exception is LockTableCommand(), which is still behaving unsafely; but that seems to require some more discussion before we change it.
2009-05-12 05:11:02 +02:00
find_inheritance_children(myrelid, NoLock) != NIL)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
Message editing: remove gratuitous variations in message wording, standardize terms, add some clarifications, fix some untranslatable attempts at dynamic message building.
2003-09-25 08:58:07 +02:00
errmsg("inherited column \"%s\" must be renamed in child tables too",
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
oldattname)));
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
}
Break transformCreateStmt() into multiple routines and make transformAlterStmt() use these routines, instead of having lots of duplicate (not to mention should-have-been-duplicate) code. Adding a column with a CHECK constraint actually works now, and the tests to reject unsupported DEFAULT and NOT NULL clauses actually fire now. ALTER TABLE ADD PRIMARY KEY works, modulo having to have created the column(s) NOT NULL already.
2001-10-12 02:07:15 +02:00
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
/* rename attributes in typed tables of composite type */
if (targetrelation->rd_rel->relkind == RELKIND_COMPOSITE_TYPE)
{
List *child_oids;
ListCell *lo;
child_oids = find_typed_table_dependencies(targetrelation->rd_rel->reltype,
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
RelationGetRelationName(targetrelation),
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
behavior);
foreach(lo, child_oids)
renameatt_internal(lfirst_oid(lo), oldattname, newattname, true, true, 0, behavior);
}
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
attrelation = heap_open(AttributeRelationId, RowExclusiveLock);
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
atttup = SearchSysCacheCopyAttName(myrelid, oldattname);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
if (!HeapTupleIsValid(atttup))
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_COLUMN),
Message editing: remove gratuitous variations in message wording, standardize terms, add some clarifications, fix some untranslatable attempts at dynamic message building.
2003-09-25 08:58:07 +02:00
errmsg("column \"%s\" does not exist",
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
oldattname)));
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
attform = (Form_pg_attribute) GETSTRUCT(atttup);
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
attnum = attform->attnum;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (attnum <= 0)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
Message editing: remove gratuitous variations in message wording, standardize terms, add some clarifications, fix some untranslatable attempts at dynamic message building.
2003-09-25 08:58:07 +02:00
errmsg("cannot rename system column \"%s\"",
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
oldattname)));
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* if the attribute is inherited, forbid the renaming. if this is a
Tighten integrity checks on ALTER TABLE ... ALTER COLUMN ... RENAME. When a column is renamed, we recursively rename the same column in all descendent tables. But if one of those tables also inherits that column from a table outside the inheritance hierarchy rooted at the named table, we must throw an error. The previous coding correctly prohibited the rename when the parent had inherited the column from elsewhere, but overlooked the case where the parent was OK but a child table also inherited the same column from a second, unrelated parent. For now, not backpatched due to lack of complaints from the field. KaiGai Kohei, with further changes by me. Reviewed by Bernd Helme and Tom Lane.
2010-02-01 20:28:56 +01:00
* top-level call to renameatt(), then expected_parents will be 0, so the
* effect of this code will be to prohibit the renaming if the attribute
* is inherited at all. if this is a recursive call to renameatt(),
* expected_parents will be the number of parents the current relation has
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* within the inheritance hierarchy being processed, so we'll prohibit the
* renaming only if there are additional parents from elsewhere.
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
*/
Tighten integrity checks on ALTER TABLE ... ALTER COLUMN ... RENAME. When a column is renamed, we recursively rename the same column in all descendent tables. But if one of those tables also inherits that column from a table outside the inheritance hierarchy rooted at the named table, we must throw an error. The previous coding correctly prohibited the rename when the parent had inherited the column from elsewhere, but overlooked the case where the parent was OK but a child table also inherited the same column from a second, unrelated parent. For now, not backpatched due to lack of complaints from the field. KaiGai Kohei, with further changes by me. Reviewed by Bernd Helme and Tom Lane.
2010-02-01 20:28:56 +01:00
if (attform->attinhcount > expected_parents)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
Message editing: remove gratuitous variations in message wording, standardize terms, add some clarifications, fix some untranslatable attempts at dynamic message building.
2003-09-25 08:58:07 +02:00
errmsg("cannot rename inherited column \"%s\"",
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
oldattname)));
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
Remove code that attempted to rename index columns to keep them in sync with their underlying table columns. That code was not bright enough to cope with collision situations (ie, new name conflicts with some other column of the index). Since there is no functional reason to do this at all, trying to upgrade the logic to be bulletproof doesn't seem worth the trouble. This change means that both the index name and the column names of an index are set when it's created, and won't be automatically changed when the underlying table columns are renamed. Neatnik DBAs are still free to rename them manually, of course.
2009-12-23 17:43:43 +01:00
/* new name should not already exist */
Be more clear when a new column name collides with a system column name. We now use the same error message for ALTER TABLE .. ADD COLUMN or ALTER TABLE .. RENAME COLUMN that we do for CREATE TABLE. The old message was accurate, but might be confusing to users not aware of our system columns. Vik Reykja, with some changes by me, and further proofreading by Tom Lane
2012-01-26 18:44:30 +01:00
check_for_column_name_collision(targetrelation, newattname);
Reimplement temp tables using schemas. The temp table map is history; temp table entries in pg_class have the names the user would expect.
2002-03-31 08:26:32 +02:00
Remove code that attempted to rename index columns to keep them in sync with their underlying table columns. That code was not bright enough to cope with collision situations (ie, new name conflicts with some other column of the index). Since there is no functional reason to do this at all, trying to upgrade the logic to be bulletproof doesn't seem worth the trouble. This change means that both the index name and the column names of an index are set when it's created, and won't be automatically changed when the underlying table columns are renamed. Neatnik DBAs are still free to rename them manually, of course.
2009-12-23 17:43:43 +01:00
/* apply the update */
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
namestrcpy(&(attform->attname), newattname);
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
simple_heap_update(attrelation, &atttup->t_self, atttup);
Added ALTER TABLE ... ADD CONSTRAINT (provided by Stephan Szabo). Added constraint dumping capability to pg_dump (also from Stephan) Fixed DROP TABLE -> RelationBuildTriggers: 2 record(s) not found for rel error. Fixed little error in gram.y I made the last days. Jan
2000-02-04 19:49:34 +01:00
Restructure system-catalog index updating logic. Instead of having hardwired lists of index names for each catalog, use the relcache's mechanism for caching lists of OIDs of indexes of any table. This reduces the common case of updating system catalog indexes to a single line, makes it much easier to add a new system index (in fact, you can now do so on-the-fly if you want to), and as a nice side benefit improves performance a little. Per recent pghackers discussion.
2002-08-05 05:29:17 +02:00
/* keep system catalog indexes current */
CatalogUpdateIndexes(attrelation, atttup);
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
InvokeObjectPostAlterHook(RelationRelationId, myrelid, attnum);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
heap_freetuple(atttup);
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
heap_close(attrelation, RowExclusiveLock);
Add tgconstrrelid to stored Trigger structures, make RI trigger functions depend on this rather than the trigger argument strings to locate the other relation to test. This makes RI triggers function properly in the presence of schemas and temp tables. Along the way, fix bogus lack of locking in RI triggers, handle quoting of names fully correctly, compute required sizes of query buffers with some semblance of accuracy.
2002-04-02 00:36:13 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
relation_close(targetrelation, NoLock); /* close rel but keep lock */
Included all yacc and lex files into the distribution.
2000-01-16 21:05:00 +01:00
}
Improve behavior of concurrent rename statements. Previously, renaming a table, sequence, view, index, foreign table, column, or trigger checked permissions before locking the object, which meant that if permissions were revoked during the lock wait, we would still allow the operation. Similarly, if the original object is dropped and a new one with the same name is created, the operation will be allowed if we had permissions on the old object; the permissions on the new object don't matter. All this is now fixed. Along the way, attempting to rename a trigger on a foreign table now gives the same error message as trying to create one there in the first place (i.e. that it's not a table or view) rather than simply stating that no trigger by that name exists. Patch by me; review by Noah Misch.
2011-12-16 00:51:46 +01:00
/*
* Perform permissions and integrity checks before acquiring a relation lock.
*/
static void
RangeVarCallbackForRenameAttribute(const RangeVar *rv, Oid relid, Oid oldrelid,
void *arg)
{
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
HeapTuple tuple;
Form_pg_class form;
Improve behavior of concurrent rename statements. Previously, renaming a table, sequence, view, index, foreign table, column, or trigger checked permissions before locking the object, which meant that if permissions were revoked during the lock wait, we would still allow the operation. Similarly, if the original object is dropped and a new one with the same name is created, the operation will be allowed if we had permissions on the old object; the permissions on the new object don't matter. All this is now fixed. Along the way, attempting to rename a trigger on a foreign table now gives the same error message as trying to create one there in the first place (i.e. that it's not a table or view) rather than simply stating that no trigger by that name exists. Patch by me; review by Noah Misch.
2011-12-16 00:51:46 +01:00
tuple = SearchSysCache1(RELOID, ObjectIdGetDatum(relid));
if (!HeapTupleIsValid(tuple))
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
return; /* concurrently dropped */
Improve behavior of concurrent rename statements. Previously, renaming a table, sequence, view, index, foreign table, column, or trigger checked permissions before locking the object, which meant that if permissions were revoked during the lock wait, we would still allow the operation. Similarly, if the original object is dropped and a new one with the same name is created, the operation will be allowed if we had permissions on the old object; the permissions on the new object don't matter. All this is now fixed. Along the way, attempting to rename a trigger on a foreign table now gives the same error message as trying to create one there in the first place (i.e. that it's not a table or view) rather than simply stating that no trigger by that name exists. Patch by me; review by Noah Misch.
2011-12-16 00:51:46 +01:00
form = (Form_pg_class) GETSTRUCT(tuple);
renameatt_check(relid, form, false);
ReleaseSysCache(tuple);
}
Support ALTER TYPE RENAME. Petr Jelinek
2008-03-19 19:38:30 +01:00
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
/*
* renameatt - changes the name of a attribute in a relation
*/
Adjust many backend functions to return OID rather than void. Extracted from a larger patch by Dimitri Fontaine. It is hoped that this will provide infrastructure for enriching the new event trigger functionality, but it seems possibly useful for other purposes as well.
2012-12-24 00:25:03 +01:00
Oid
Improve behavior of concurrent rename statements. Previously, renaming a table, sequence, view, index, foreign table, column, or trigger checked permissions before locking the object, which meant that if permissions were revoked during the lock wait, we would still allow the operation. Similarly, if the original object is dropped and a new one with the same name is created, the operation will be allowed if we had permissions on the old object; the permissions on the new object don't matter. All this is now fixed. Along the way, attempting to rename a trigger on a foreign table now gives the same error message as trying to create one there in the first place (i.e. that it's not a table or view) rather than simply stating that no trigger by that name exists. Patch by me; review by Noah Misch.
2011-12-16 00:51:46 +01:00
renameatt(RenameStmt *stmt)
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
{
Improve behavior of concurrent rename statements. Previously, renaming a table, sequence, view, index, foreign table, column, or trigger checked permissions before locking the object, which meant that if permissions were revoked during the lock wait, we would still allow the operation. Similarly, if the original object is dropped and a new one with the same name is created, the operation will be allowed if we had permissions on the old object; the permissions on the new object don't matter. All this is now fixed. Along the way, attempting to rename a trigger on a foreign table now gives the same error message as trying to create one there in the first place (i.e. that it's not a table or view) rather than simply stating that no trigger by that name exists. Patch by me; review by Noah Misch.
2011-12-16 00:51:46 +01:00
Oid relid;
/* lock level taken here should match renameatt_internal */
relid = RangeVarGetRelidExtended(stmt->relation, AccessExclusiveLock,
ALTER <thing> [IF EXISTS] ... allows silent DDL if required, e.g. ALTER FOREIGN TABLE IF EXISTS foo RENAME TO bar Pavel Stehule
2012-01-24 00:25:04 +01:00
stmt->missing_ok, false,
Improve behavior of concurrent rename statements. Previously, renaming a table, sequence, view, index, foreign table, column, or trigger checked permissions before locking the object, which meant that if permissions were revoked during the lock wait, we would still allow the operation. Similarly, if the original object is dropped and a new one with the same name is created, the operation will be allowed if we had permissions on the old object; the permissions on the new object don't matter. All this is now fixed. Along the way, attempting to rename a trigger on a foreign table now gives the same error message as trying to create one there in the first place (i.e. that it's not a table or view) rather than simply stating that no trigger by that name exists. Patch by me; review by Noah Misch.
2011-12-16 00:51:46 +01:00
RangeVarCallbackForRenameAttribute,
NULL);
ALTER <thing> [IF EXISTS] ... allows silent DDL if required, e.g. ALTER FOREIGN TABLE IF EXISTS foo RENAME TO bar Pavel Stehule
2012-01-24 00:25:04 +01:00
if (!OidIsValid(relid))
{
ereport(NOTICE,
(errmsg("relation \"%s\" does not exist, skipping",
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
stmt->relation->relname)));
Adjust many backend functions to return OID rather than void. Extracted from a larger patch by Dimitri Fontaine. It is hoped that this will provide infrastructure for enriching the new event trigger functionality, but it seems possibly useful for other purposes as well.
2012-12-24 00:25:03 +01:00
return InvalidOid;
ALTER <thing> [IF EXISTS] ... allows silent DDL if required, e.g. ALTER FOREIGN TABLE IF EXISTS foo RENAME TO bar Pavel Stehule
2012-01-24 00:25:04 +01:00
}
Improve behavior of concurrent rename statements. Previously, renaming a table, sequence, view, index, foreign table, column, or trigger checked permissions before locking the object, which meant that if permissions were revoked during the lock wait, we would still allow the operation. Similarly, if the original object is dropped and a new one with the same name is created, the operation will be allowed if we had permissions on the old object; the permissions on the new object don't matter. All this is now fixed. Along the way, attempting to rename a trigger on a foreign table now gives the same error message as trying to create one there in the first place (i.e. that it's not a table or view) rather than simply stating that no trigger by that name exists. Patch by me; review by Noah Misch.
2011-12-16 00:51:46 +01:00
renameatt_internal(relid,
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
stmt->subname, /* old att name */
stmt->newname, /* new att name */
interpretInhOption(stmt->relation->inhOpt), /* recursive? */
false, /* recursing? */
0, /* expected inhcount */
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
stmt->behavior);
Adjust many backend functions to return OID rather than void. Extracted from a larger patch by Dimitri Fontaine. It is hoped that this will provide infrastructure for enriching the new event trigger functionality, but it seems possibly useful for other purposes as well.
2012-12-24 00:25:03 +01:00
/* This is an ALTER TABLE command so it's about the relid */
return relid;
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
}
Add support for renaming constraints reviewed by Josh Berkus and Dimitri Fontaine
2012-03-10 19:19:13 +01:00
/*
* same logic as renameatt_internal
*/
Adjust many backend functions to return OID rather than void. Extracted from a larger patch by Dimitri Fontaine. It is hoped that this will provide infrastructure for enriching the new event trigger functionality, but it seems possibly useful for other purposes as well.
2012-12-24 00:25:03 +01:00
static Oid
Add support for renaming constraints reviewed by Josh Berkus and Dimitri Fontaine
2012-03-10 19:19:13 +01:00
rename_constraint_internal(Oid myrelid,
Add support for renaming domain constraints
2012-04-03 07:11:51 +02:00
Oid mytypid,
Add support for renaming constraints reviewed by Josh Berkus and Dimitri Fontaine
2012-03-10 19:19:13 +01:00
const char *oldconname,
const char *newconname,
bool recurse,
bool recursing,
int expected_parents)
{
Add support for renaming domain constraints
2012-04-03 07:11:51 +02:00
Relation targetrelation = NULL;
Add support for renaming constraints reviewed by Josh Berkus and Dimitri Fontaine
2012-03-10 19:19:13 +01:00
Oid constraintOid;
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
HeapTuple tuple;
Add support for renaming constraints reviewed by Josh Berkus and Dimitri Fontaine
2012-03-10 19:19:13 +01:00
Form_pg_constraint con;
Add support for renaming domain constraints
2012-04-03 07:11:51 +02:00
AssertArg(!myrelid || !mytypid);
if (mytypid)
{
constraintOid = get_domain_constraint_oid(mytypid, oldconname, false);
}
else
{
targetrelation = relation_open(myrelid, AccessExclusiveLock);
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
/*
* don't tell it whether we're recursing; we allow changing typed
* tables here
*/
Add support for renaming domain constraints
2012-04-03 07:11:51 +02:00
renameatt_check(myrelid, RelationGetForm(targetrelation), false);
Add support for renaming constraints reviewed by Josh Berkus and Dimitri Fontaine
2012-03-10 19:19:13 +01:00
Add support for renaming domain constraints
2012-04-03 07:11:51 +02:00
constraintOid = get_relation_constraint_oid(myrelid, oldconname, false);
}
Add support for renaming constraints reviewed by Josh Berkus and Dimitri Fontaine
2012-03-10 19:19:13 +01:00
tuple = SearchSysCache1(CONSTROID, ObjectIdGetDatum(constraintOid));
if (!HeapTupleIsValid(tuple))
elog(ERROR, "cache lookup failed for constraint %u",
constraintOid);
con = (Form_pg_constraint) GETSTRUCT(tuple);
Recast "ONLY" column CHECK constraints as NO INHERIT The original syntax wasn't universally loved, and it didn't allow its usage in CREATE TABLE, only ALTER TABLE. It now works everywhere, and it also allows using ALTER TABLE ONLY to add an uninherited CHECK constraint, per discussion. The pg_constraint column has accordingly been renamed connoinherit. This commit partly reverts some of the changes in 61d81bd28dbec65a6b144e0cd3d0bfe25913c3ac, particularly some pg_dump and psql bits, because now pg_get_constraintdef includes the necessary NO INHERIT within the constraint definition. Author: Nikhil Sontakke Some tweaks by me
2012-04-21 04:46:20 +02:00
if (myrelid && con->contype == CONSTRAINT_CHECK && !con->connoinherit)
Add support for renaming constraints reviewed by Josh Berkus and Dimitri Fontaine
2012-03-10 19:19:13 +01:00
{
if (recurse)
{
List *child_oids,
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
*child_numparents;
Add support for renaming constraints reviewed by Josh Berkus and Dimitri Fontaine
2012-03-10 19:19:13 +01:00
ListCell *lo,
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
*li;
Add support for renaming constraints reviewed by Josh Berkus and Dimitri Fontaine
2012-03-10 19:19:13 +01:00
child_oids = find_all_inheritors(myrelid, AccessExclusiveLock,
&child_numparents);
forboth(lo, child_oids, li, child_numparents)
{
Oid childrelid = lfirst_oid(lo);
int numparents = lfirst_int(li);
if (childrelid == myrelid)
continue;
Add support for renaming domain constraints
2012-04-03 07:11:51 +02:00
rename_constraint_internal(childrelid, InvalidOid, oldconname, newconname, false, true, numparents);
Add support for renaming constraints reviewed by Josh Berkus and Dimitri Fontaine
2012-03-10 19:19:13 +01:00
}
}
else
{
if (expected_parents == 0 &&
find_inheritance_children(myrelid, NoLock) != NIL)
ereport(ERROR,
(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
errmsg("inherited constraint \"%s\" must be renamed in child tables too",
oldconname)));
}
if (con->coninhcount > expected_parents)
ereport(ERROR,
(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
errmsg("cannot rename inherited constraint \"%s\"",
oldconname)));
}
if (con->conindid
&& (con->contype == CONSTRAINT_PRIMARY
|| con->contype == CONSTRAINT_UNIQUE
|| con->contype == CONSTRAINT_EXCLUSION))
/* rename the index; this renames the constraint as well */
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
RenameRelationInternal(con->conindid, newconname, false);
Add support for renaming constraints reviewed by Josh Berkus and Dimitri Fontaine
2012-03-10 19:19:13 +01:00
else
RenameConstraintById(constraintOid, newconname);
ReleaseSysCache(tuple);
Add support for renaming domain constraints
2012-04-03 07:11:51 +02:00
if (targetrelation)
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
relation_close(targetrelation, NoLock); /* close rel but keep lock */
Adjust many backend functions to return OID rather than void. Extracted from a larger patch by Dimitri Fontaine. It is hoped that this will provide infrastructure for enriching the new event trigger functionality, but it seems possibly useful for other purposes as well.
2012-12-24 00:25:03 +01:00
return constraintOid;
Add support for renaming constraints reviewed by Josh Berkus and Dimitri Fontaine
2012-03-10 19:19:13 +01:00
}
Adjust many backend functions to return OID rather than void. Extracted from a larger patch by Dimitri Fontaine. It is hoped that this will provide infrastructure for enriching the new event trigger functionality, but it seems possibly useful for other purposes as well.
2012-12-24 00:25:03 +01:00
Oid
Add support for renaming constraints reviewed by Josh Berkus and Dimitri Fontaine
2012-03-10 19:19:13 +01:00
RenameConstraint(RenameStmt *stmt)
{
Add support for renaming domain constraints
2012-04-03 07:11:51 +02:00
Oid relid = InvalidOid;
Oid typid = InvalidOid;
Add support for renaming constraints reviewed by Josh Berkus and Dimitri Fontaine
2012-03-10 19:19:13 +01:00
Add support for renaming domain constraints
2012-04-03 07:11:51 +02:00
if (stmt->relationType == OBJECT_DOMAIN)
{
Relation rel;
HeapTuple tup;
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
typid = typenameTypeId(NULL, makeTypeNameFromNameList(stmt->object));
Add support for renaming domain constraints
2012-04-03 07:11:51 +02:00
rel = heap_open(TypeRelationId, RowExclusiveLock);
tup = SearchSysCache1(TYPEOID, ObjectIdGetDatum(typid));
if (!HeapTupleIsValid(tup))
elog(ERROR, "cache lookup failed for type %u", typid);
checkDomainOwner(tup);
ReleaseSysCache(tup);
heap_close(rel, NoLock);
}
else
{
/* lock level taken here should match rename_constraint_internal */
relid = RangeVarGetRelidExtended(stmt->relation, AccessExclusiveLock,
false, false,
RangeVarCallbackForRenameAttribute,
NULL);
}
Add support for renaming constraints reviewed by Josh Berkus and Dimitri Fontaine
2012-03-10 19:19:13 +01:00
Adjust many backend functions to return OID rather than void. Extracted from a larger patch by Dimitri Fontaine. It is hoped that this will provide infrastructure for enriching the new event trigger functionality, but it seems possibly useful for other purposes as well.
2012-12-24 00:25:03 +01:00
return
rename_constraint_internal(relid, typid,
stmt->subname,
stmt->newname,
pgindent run for release 9.3 This is the first run of the Perl-based pgindent script. Also update pgindent instructions.
2013-05-29 22:58:43 +02:00
stmt->relation ? interpretInhOption(stmt->relation->inhOpt) : false, /* recursive? */
false, /* recursing? */
Adjust many backend functions to return OID rather than void. Extracted from a larger patch by Dimitri Fontaine. It is hoped that this will provide infrastructure for enriching the new event trigger functionality, but it seems possibly useful for other purposes as well.
2012-12-24 00:25:03 +01:00
0 /* expected inhcount */ );
Add support for renaming constraints reviewed by Josh Berkus and Dimitri Fontaine
2012-03-10 19:19:13 +01:00
}
Improve behavior of concurrent rename statements. Previously, renaming a table, sequence, view, index, foreign table, column, or trigger checked permissions before locking the object, which meant that if permissions were revoked during the lock wait, we would still allow the operation. Similarly, if the original object is dropped and a new one with the same name is created, the operation will be allowed if we had permissions on the old object; the permissions on the new object don't matter. All this is now fixed. Along the way, attempting to rename a trigger on a foreign table now gives the same error message as trying to create one there in the first place (i.e. that it's not a table or view) rather than simply stating that no trigger by that name exists. Patch by me; review by Noah Misch.
2011-12-16 00:51:46 +01:00
/*
* Execute ALTER TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE RENAME
*/
Adjust many backend functions to return OID rather than void. Extracted from a larger patch by Dimitri Fontaine. It is hoped that this will provide infrastructure for enriching the new event trigger functionality, but it seems possibly useful for other purposes as well.
2012-12-24 00:25:03 +01:00
Oid
Improve behavior of concurrent rename statements. Previously, renaming a table, sequence, view, index, foreign table, column, or trigger checked permissions before locking the object, which meant that if permissions were revoked during the lock wait, we would still allow the operation. Similarly, if the original object is dropped and a new one with the same name is created, the operation will be allowed if we had permissions on the old object; the permissions on the new object don't matter. All this is now fixed. Along the way, attempting to rename a trigger on a foreign table now gives the same error message as trying to create one there in the first place (i.e. that it's not a table or view) rather than simply stating that no trigger by that name exists. Patch by me; review by Noah Misch.
2011-12-16 00:51:46 +01:00
RenameRelation(RenameStmt *stmt)
{
Oid relid;
Support ALTER TYPE RENAME. Petr Jelinek
2008-03-19 19:38:30 +01:00
/*
Improve behavior of concurrent rename statements. Previously, renaming a table, sequence, view, index, foreign table, column, or trigger checked permissions before locking the object, which meant that if permissions were revoked during the lock wait, we would still allow the operation. Similarly, if the original object is dropped and a new one with the same name is created, the operation will be allowed if we had permissions on the old object; the permissions on the new object don't matter. All this is now fixed. Along the way, attempting to rename a trigger on a foreign table now gives the same error message as trying to create one there in the first place (i.e. that it's not a table or view) rather than simply stating that no trigger by that name exists. Patch by me; review by Noah Misch.
2011-12-16 00:51:46 +01:00
* Grab an exclusive lock on the target table, index, sequence or view,
* which we will NOT release until end of transaction.
*
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* Lock level used here should match RenameRelationInternal, to avoid lock
* escalation.
Support ALTER TYPE RENAME. Petr Jelinek
2008-03-19 19:38:30 +01:00
*/
Improve behavior of concurrent rename statements. Previously, renaming a table, sequence, view, index, foreign table, column, or trigger checked permissions before locking the object, which meant that if permissions were revoked during the lock wait, we would still allow the operation. Similarly, if the original object is dropped and a new one with the same name is created, the operation will be allowed if we had permissions on the old object; the permissions on the new object don't matter. All this is now fixed. Along the way, attempting to rename a trigger on a foreign table now gives the same error message as trying to create one there in the first place (i.e. that it's not a table or view) rather than simply stating that no trigger by that name exists. Patch by me; review by Noah Misch.
2011-12-16 00:51:46 +01:00
relid = RangeVarGetRelidExtended(stmt->relation, AccessExclusiveLock,
ALTER <thing> [IF EXISTS] ... allows silent DDL if required, e.g. ALTER FOREIGN TABLE IF EXISTS foo RENAME TO bar Pavel Stehule
2012-01-24 00:25:04 +01:00
stmt->missing_ok, false,
Improve behavior of concurrent ALTER TABLE, and do some refactoring. ALTER TABLE (and ALTER VIEW, ALTER SEQUENCE, etc.) now use a RangeVarGetRelid callback to check permissions before acquiring a table lock. We also now use the same callback for all forms of ALTER TABLE, rather than having separate, almost-identical callbacks for ALTER TABLE .. SET SCHEMA and ALTER TABLE .. RENAME, and no callback at all for everything else. I went ahead and changed the code so that no form of ALTER TABLE works on foreign tables; you must use ALTER FOREIGN TABLE instead. In 9.1, it was possible to use ALTER TABLE .. SET SCHEMA or ALTER TABLE .. RENAME on a foreign table, but not any other form of ALTER TABLE, which did not seem terribly useful or consistent. Patch by me; review by Noah Misch.
2012-01-07 04:42:26 +01:00
RangeVarCallbackForAlterRelation,
Improve behavior of concurrent rename statements. Previously, renaming a table, sequence, view, index, foreign table, column, or trigger checked permissions before locking the object, which meant that if permissions were revoked during the lock wait, we would still allow the operation. Similarly, if the original object is dropped and a new one with the same name is created, the operation will be allowed if we had permissions on the old object; the permissions on the new object don't matter. All this is now fixed. Along the way, attempting to rename a trigger on a foreign table now gives the same error message as trying to create one there in the first place (i.e. that it's not a table or view) rather than simply stating that no trigger by that name exists. Patch by me; review by Noah Misch.
2011-12-16 00:51:46 +01:00
(void *) stmt);
ALTER <thing> [IF EXISTS] ... allows silent DDL if required, e.g. ALTER FOREIGN TABLE IF EXISTS foo RENAME TO bar Pavel Stehule
2012-01-24 00:25:04 +01:00
if (!OidIsValid(relid))
{
ereport(NOTICE,
(errmsg("relation \"%s\" does not exist, skipping",
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
stmt->relation->relname)));
Adjust many backend functions to return OID rather than void. Extracted from a larger patch by Dimitri Fontaine. It is hoped that this will provide infrastructure for enriching the new event trigger functionality, but it seems possibly useful for other purposes as well.
2012-12-24 00:25:03 +01:00
return InvalidOid;
ALTER <thing> [IF EXISTS] ... allows silent DDL if required, e.g. ALTER FOREIGN TABLE IF EXISTS foo RENAME TO bar Pavel Stehule
2012-01-24 00:25:04 +01:00
}
Improve behavior of concurrent rename statements. Previously, renaming a table, sequence, view, index, foreign table, column, or trigger checked permissions before locking the object, which meant that if permissions were revoked during the lock wait, we would still allow the operation. Similarly, if the original object is dropped and a new one with the same name is created, the operation will be allowed if we had permissions on the old object; the permissions on the new object don't matter. All this is now fixed. Along the way, attempting to rename a trigger on a foreign table now gives the same error message as trying to create one there in the first place (i.e. that it's not a table or view) rather than simply stating that no trigger by that name exists. Patch by me; review by Noah Misch.
2011-12-16 00:51:46 +01:00
/* Do the work */
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
RenameRelationInternal(relid, stmt->newname, false);
Adjust many backend functions to return OID rather than void. Extracted from a larger patch by Dimitri Fontaine. It is hoped that this will provide infrastructure for enriching the new event trigger functionality, but it seems possibly useful for other purposes as well.
2012-12-24 00:25:03 +01:00
return relid;
Support ALTER TYPE RENAME. Petr Jelinek
2008-03-19 19:38:30 +01:00
}
/*
* RenameRelationInternal - change the name of a relation
*
* XXX - When renaming sequences, we don't bother to modify the
* sequence name that is stored within the sequence itself
* (this would cause problems with MVCC). In the future,
* the sequence name should probably be removed from the
* sequence, AFAIK there's no need for it to be there.
*/
void
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
RenameRelationInternal(Oid myrelid, const char *newrelname, bool is_internal)
Support ALTER TYPE RENAME. Petr Jelinek
2008-03-19 19:38:30 +01:00
{
Relation targetrelation;
Relation relrelation; /* for RELATION relation */
HeapTuple reltup;
Form_pg_class relform;
Improve behavior of concurrent rename statements. Previously, renaming a table, sequence, view, index, foreign table, column, or trigger checked permissions before locking the object, which meant that if permissions were revoked during the lock wait, we would still allow the operation. Similarly, if the original object is dropped and a new one with the same name is created, the operation will be allowed if we had permissions on the old object; the permissions on the new object don't matter. All this is now fixed. Along the way, attempting to rename a trigger on a foreign table now gives the same error message as trying to create one there in the first place (i.e. that it's not a table or view) rather than simply stating that no trigger by that name exists. Patch by me; review by Noah Misch.
2011-12-16 00:51:46 +01:00
Oid namespaceId;
Support ALTER TYPE RENAME. Petr Jelinek
2008-03-19 19:38:30 +01:00
/*
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* Grab an exclusive lock on the target table, index, sequence or view,
* which we will NOT release until end of transaction.
Support ALTER TYPE RENAME. Petr Jelinek
2008-03-19 19:38:30 +01:00
*/
targetrelation = relation_open(myrelid, AccessExclusiveLock);
Improve behavior of concurrent rename statements. Previously, renaming a table, sequence, view, index, foreign table, column, or trigger checked permissions before locking the object, which meant that if permissions were revoked during the lock wait, we would still allow the operation. Similarly, if the original object is dropped and a new one with the same name is created, the operation will be allowed if we had permissions on the old object; the permissions on the new object don't matter. All this is now fixed. Along the way, attempting to rename a trigger on a foreign table now gives the same error message as trying to create one there in the first place (i.e. that it's not a table or view) rather than simply stating that no trigger by that name exists. Patch by me; review by Noah Misch.
2011-12-16 00:51:46 +01:00
namespaceId = RelationGetNamespace(targetrelation);
Attached is my patch that adds DROP CONSTRAINT support to PostgreSQL. I basically want your guys feedback. I have sprinkled some of my q's thru the text delimited with the @@ symbol. It seems to work perfectly. [ Removed @@ comments because patch was reviewed. ] At the moment it does CHECK constraints only, with inheritance. However, due to the problem mentioned before with the mismatching between inherited constraints it may be wise to disable the inheritance feature for a while. it is written in an extensible fashion to support future dropping of other types of constraint, and is well documented. Please send me your comments, check my use of locking, updating of indices, use of ERROR and NOTICE, etc. and I will rework the patch based on feedback until everyone is happy with it... Christopher Kings
2001-05-30 14:57:36 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Find relation's pg_class tuple, and make sure newrelname isn't in use.
Attached is my patch that adds DROP CONSTRAINT support to PostgreSQL. I basically want your guys feedback. I have sprinkled some of my q's thru the text delimited with the @@ symbol. It seems to work perfectly. [ Removed @@ comments because patch was reviewed. ] At the moment it does CHECK constraints only, with inheritance. However, due to the problem mentioned before with the mismatching between inherited constraints it may be wise to disable the inheritance feature for a while. it is written in an extensible fashion to support future dropping of other types of constraint, and is well documented. Please send me your comments, check my use of locking, updating of indices, use of ERROR and NOTICE, etc. and I will rework the patch based on feedback until everyone is happy with it... Christopher Kings
2001-05-30 14:57:36 +02:00
*/
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
relrelation = heap_open(RelationRelationId, RowExclusiveLock);
Attached is my patch that adds DROP CONSTRAINT support to PostgreSQL. I basically want your guys feedback. I have sprinkled some of my q's thru the text delimited with the @@ symbol. It seems to work perfectly. [ Removed @@ comments because patch was reviewed. ] At the moment it does CHECK constraints only, with inheritance. However, due to the problem mentioned before with the mismatching between inherited constraints it may be wise to disable the inheritance feature for a while. it is written in an extensible fashion to support future dropping of other types of constraint, and is well documented. Please send me your comments, check my use of locking, updating of indices, use of ERROR and NOTICE, etc. and I will rework the patch based on feedback until everyone is happy with it... Christopher Kings
2001-05-30 14:57:36 +02:00
Wrap calls to SearchSysCache and related functions using macros. The purpose of this change is to eliminate the need for every caller of SearchSysCache, SearchSysCacheCopy, SearchSysCacheExists, GetSysCacheOid, and SearchSysCacheList to know the maximum number of allowable keys for a syscache entry (currently 4). This will make it far easier to increase the maximum number of keys in a future release should we choose to do so, and it makes the code shorter, too. Design and review by Tom Lane.
2010-02-14 19:42:19 +01:00
reltup = SearchSysCacheCopy1(RELOID, ObjectIdGetDatum(myrelid));
pgindent run.
2003-08-04 02:43:34 +02:00
if (!HeapTupleIsValid(reltup)) /* shouldn't happen */
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
elog(ERROR, "cache lookup failed for relation %u", myrelid);
Fix the problem that creating a user-defined type named _foo, followed by one 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.
2007-05-12 02:55:00 +02:00
relform = (Form_pg_class) GETSTRUCT(reltup);
pg_type has a typnamespace column; system now supports creating types in different namespaces. Also, cleanup work on relation namespace support: drop, alter, rename commands work for tables in non-default namespaces.
2002-03-29 20:06:29 +01:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
if (get_relname_relid(newrelname, namespaceId) != InvalidOid)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_DUPLICATE_TABLE),
errmsg("relation \"%s\" already exists",
newrelname)));
Change the aclchk.c routines to uniformly use OIDs to identify the objects to be privilege-checked. Some change in their APIs would be necessary no matter what in the schema environment, and simply getting rid of the name-based interface entirely seems like the best way.
2002-03-22 00:27:25 +01:00
Attached is my patch that adds DROP CONSTRAINT support to PostgreSQL. I basically want your guys feedback. I have sprinkled some of my q's thru the text delimited with the @@ symbol. It seems to work perfectly. [ Removed @@ comments because patch was reviewed. ] At the moment it does CHECK constraints only, with inheritance. However, due to the problem mentioned before with the mismatching between inherited constraints it may be wise to disable the inheritance feature for a while. it is written in an extensible fashion to support future dropping of other types of constraint, and is well documented. Please send me your comments, check my use of locking, updating of indices, use of ERROR and NOTICE, etc. and I will rework the patch based on feedback until everyone is happy with it... Christopher Kings
2001-05-30 14:57:36 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Update pg_class tuple with new relname. (Scribbling on reltup is OK
* because it's a copy...)
Attached is my patch that adds DROP CONSTRAINT support to PostgreSQL. I basically want your guys feedback. I have sprinkled some of my q's thru the text delimited with the @@ symbol. It seems to work perfectly. [ Removed @@ comments because patch was reviewed. ] At the moment it does CHECK constraints only, with inheritance. However, due to the problem mentioned before with the mismatching between inherited constraints it may be wise to disable the inheritance feature for a while. it is written in an extensible fashion to support future dropping of other types of constraint, and is well documented. Please send me your comments, check my use of locking, updating of indices, use of ERROR and NOTICE, etc. and I will rework the patch based on feedback until everyone is happy with it... Christopher Kings
2001-05-30 14:57:36 +02:00
*/
Fix the problem that creating a user-defined type named _foo, followed by one 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.
2007-05-12 02:55:00 +02:00
namestrcpy(&(relform->relname), newrelname);
Attached is my patch that adds DROP CONSTRAINT support to PostgreSQL. I basically want your guys feedback. I have sprinkled some of my q's thru the text delimited with the @@ symbol. It seems to work perfectly. [ Removed @@ comments because patch was reviewed. ] At the moment it does CHECK constraints only, with inheritance. However, due to the problem mentioned before with the mismatching between inherited constraints it may be wise to disable the inheritance feature for a while. it is written in an extensible fashion to support future dropping of other types of constraint, and is well documented. Please send me your comments, check my use of locking, updating of indices, use of ERROR and NOTICE, etc. and I will rework the patch based on feedback until everyone is happy with it... Christopher Kings
2001-05-30 14:57:36 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
simple_heap_update(relrelation, &reltup->t_self, reltup);
Restructure system-catalog index updating logic. Instead of having hardwired lists of index names for each catalog, use the relcache's mechanism for caching lists of OIDs of indexes of any table. This reduces the common case of updating system catalog indexes to a single line, makes it much easier to add a new system index (in fact, you can now do so on-the-fly if you want to), and as a nice side benefit improves performance a little. Per recent pghackers discussion.
2002-08-05 05:29:17 +02:00
/* keep the system catalog indexes current */
CatalogUpdateIndexes(relrelation, reltup);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
InvokeObjectPostAlterHookArg(RelationRelationId, myrelid, 0,
InvalidOid, is_internal);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
heap_freetuple(reltup);
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
heap_close(relrelation, RowExclusiveLock);
Attached is my patch that adds DROP CONSTRAINT support to PostgreSQL. I basically want your guys feedback. I have sprinkled some of my q's thru the text delimited with the @@ symbol. It seems to work perfectly. [ Removed @@ comments because patch was reviewed. ] At the moment it does CHECK constraints only, with inheritance. However, due to the problem mentioned before with the mismatching between inherited constraints it may be wise to disable the inheritance feature for a while. it is written in an extensible fashion to support future dropping of other types of constraint, and is well documented. Please send me your comments, check my use of locking, updating of indices, use of ERROR and NOTICE, etc. and I will rework the patch based on feedback until everyone is happy with it... Christopher Kings
2001-05-30 14:57:36 +02:00
/*
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
* Also rename the associated type, if any.
Attached is my patch that adds DROP CONSTRAINT support to PostgreSQL. I basically want your guys feedback. I have sprinkled some of my q's thru the text delimited with the @@ symbol. It seems to work perfectly. [ Removed @@ comments because patch was reviewed. ] At the moment it does CHECK constraints only, with inheritance. However, due to the problem mentioned before with the mismatching between inherited constraints it may be wise to disable the inheritance feature for a while. it is written in an extensible fashion to support future dropping of other types of constraint, and is well documented. Please send me your comments, check my use of locking, updating of indices, use of ERROR and NOTICE, etc. and I will rework the patch based on feedback until everyone is happy with it... Christopher Kings
2001-05-30 14:57:36 +02:00
*/
Fix the problem that creating a user-defined type named _foo, followed by one 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.
2007-05-12 02:55:00 +02:00
if (OidIsValid(targetrelation->rd_rel->reltype))
Support ALTER TYPE RENAME. Petr Jelinek
2008-03-19 19:38:30 +01:00
RenameTypeInternal(targetrelation->rd_rel->reltype,
newrelname, namespaceId);
Attached is my patch that adds DROP CONSTRAINT support to PostgreSQL. I basically want your guys feedback. I have sprinkled some of my q's thru the text delimited with the @@ symbol. It seems to work perfectly. [ Removed @@ comments because patch was reviewed. ] At the moment it does CHECK constraints only, with inheritance. However, due to the problem mentioned before with the mismatching between inherited constraints it may be wise to disable the inheritance feature for a while. it is written in an extensible fashion to support future dropping of other types of constraint, and is well documented. Please send me your comments, check my use of locking, updating of indices, use of ERROR and NOTICE, etc. and I will rework the patch based on feedback until everyone is happy with it... Christopher Kings
2001-05-30 14:57:36 +02:00
Fix ALTER INDEX RENAME so that if the index belongs to a unique or primary key constraint, the constraint is renamed as well. This avoids inconsistent situations that could confuse pg_dump (not to mention humans). We might at some point provide ALTER TABLE RENAME CONSTRAINT as a more general solution, but there seems no reason not to allow doing it this way too. Per bug #3854 and related discussions.
2008-01-17 19:56:54 +01:00
/*
* Also rename the associated constraint, if any.
*/
Support ALTER TYPE RENAME. Petr Jelinek
2008-03-19 19:38:30 +01:00
if (targetrelation->rd_rel->relkind == RELKIND_INDEX)
Fix ALTER INDEX RENAME so that if the index belongs to a unique or primary key constraint, the constraint is renamed as well. This avoids inconsistent situations that could confuse pg_dump (not to mention humans). We might at some point provide ALTER TABLE RENAME CONSTRAINT as a more general solution, but there seems no reason not to allow doing it this way too. Per bug #3854 and related discussions.
2008-01-17 19:56:54 +01:00
{
Oid constraintId = get_index_constraint(myrelid);
if (OidIsValid(constraintId))
RenameConstraintById(constraintId, newrelname);
}
Attached is my patch that adds DROP CONSTRAINT support to PostgreSQL. I basically want your guys feedback. I have sprinkled some of my q's thru the text delimited with the @@ symbol. It seems to work perfectly. [ Removed @@ comments because patch was reviewed. ] At the moment it does CHECK constraints only, with inheritance. However, due to the problem mentioned before with the mismatching between inherited constraints it may be wise to disable the inheritance feature for a while. it is written in an extensible fashion to support future dropping of other types of constraint, and is well documented. Please send me your comments, check my use of locking, updating of indices, use of ERROR and NOTICE, etc. and I will rework the patch based on feedback until everyone is happy with it... Christopher Kings
2001-05-30 14:57:36 +02:00
/*
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
* Close rel, but keep exclusive lock!
Attached is my patch that adds DROP CONSTRAINT support to PostgreSQL. I basically want your guys feedback. I have sprinkled some of my q's thru the text delimited with the @@ symbol. It seems to work perfectly. [ Removed @@ comments because patch was reviewed. ] At the moment it does CHECK constraints only, with inheritance. However, due to the problem mentioned before with the mismatching between inherited constraints it may be wise to disable the inheritance feature for a while. it is written in an extensible fashion to support future dropping of other types of constraint, and is well documented. Please send me your comments, check my use of locking, updating of indices, use of ERROR and NOTICE, etc. and I will rework the patch based on feedback until everyone is happy with it... Christopher Kings
2001-05-30 14:57:36 +02:00
*/
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
relation_close(targetrelation, NoLock);
}
Attached is my patch that adds DROP CONSTRAINT support to PostgreSQL. I basically want your guys feedback. I have sprinkled some of my q's thru the text delimited with the @@ symbol. It seems to work perfectly. [ Removed @@ comments because patch was reviewed. ] At the moment it does CHECK constraints only, with inheritance. However, due to the problem mentioned before with the mismatching between inherited constraints it may be wise to disable the inheritance feature for a while. it is written in an extensible fashion to support future dropping of other types of constraint, and is well documented. Please send me your comments, check my use of locking, updating of indices, use of ERROR and NOTICE, etc. and I will rework the patch based on feedback until everyone is happy with it... Christopher Kings
2001-05-30 14:57:36 +02:00
Add checks to TRUNCATE, CLUSTER, and REINDEX to prevent performing these operations when the current transaction has any open references to the target relation or index (implying it has an active query using the relation). The need for this was previously recognized in connection with ALTER TABLE, but anything that summarily eliminates tuples or moves them around would confuse an active scan. While this patch does not in itself fix bug #3883 (the deadlock would happen before the new check fires), it will discourage people from attempting the sequence of operations that creates a deadlock risk, so it's at least a partial response to that problem. In passing, add a previously-missing check to REINDEX to prevent trying to reindex another backend's temp table. This isn't a security problem since only a superuser would get past the schema permission checks, but if we are testing for this in other utility commands then surely REINDEX should too.
2008-01-30 20:46:48 +01:00
/*
* Disallow ALTER TABLE (and similar commands) when the current backend has
* any open reference to the target table besides the one just acquired by
* the calling command; this implies there's an open cursor or active plan.
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
* We need this check because our lock doesn't protect us against stomping
* on our own foot, only other people's feet!
Add checks to TRUNCATE, CLUSTER, and REINDEX to prevent performing these operations when the current transaction has any open references to the target relation or index (implying it has an active query using the relation). The need for this was previously recognized in connection with ALTER TABLE, but anything that summarily eliminates tuples or moves them around would confuse an active scan. While this patch does not in itself fix bug #3883 (the deadlock would happen before the new check fires), it will discourage people from attempting the sequence of operations that creates a deadlock risk, so it's at least a partial response to that problem. In passing, add a previously-missing check to REINDEX to prevent trying to reindex another backend's temp table. This isn't a security problem since only a superuser would get past the schema permission checks, but if we are testing for this in other utility commands then surely REINDEX should too.
2008-01-30 20:46:48 +01:00
*
* For ALTER TABLE, the only case known to cause serious trouble is ALTER
* COLUMN TYPE, and some changes are obviously pretty benign, so this could
* possibly be relaxed to only error out for certain types of alterations.
* But the use-case for allowing any of these things is not obvious, so we
* won't work hard at it for now.
*
* We also reject these commands if there are any pending AFTER trigger events
* for the rel. This is certainly necessary for the rewriting variants of
* ALTER TABLE, because they don't preserve tuple TIDs and so the pending
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* events would try to fetch the wrong tuples. It might be overly cautious
Add checks to TRUNCATE, CLUSTER, and REINDEX to prevent performing these operations when the current transaction has any open references to the target relation or index (implying it has an active query using the relation). The need for this was previously recognized in connection with ALTER TABLE, but anything that summarily eliminates tuples or moves them around would confuse an active scan. While this patch does not in itself fix bug #3883 (the deadlock would happen before the new check fires), it will discourage people from attempting the sequence of operations that creates a deadlock risk, so it's at least a partial response to that problem. In passing, add a previously-missing check to REINDEX to prevent trying to reindex another backend's temp table. This isn't a security problem since only a superuser would get past the schema permission checks, but if we are testing for this in other utility commands then surely REINDEX should too.
2008-01-30 20:46:48 +01:00
* in other cases, but again it seems better to err on the side of paranoia.
*
* REINDEX calls this with "rel" referencing the index to be rebuilt; here
* we are worried about active indexscans on the index. The trigger-event
* check can be skipped, since we are doing no damage to the parent table.
*
* The statement name (eg, "ALTER TABLE") is passed for use in error messages.
*/
void
CheckTableNotInUse(Relation rel, const char *stmt)
{
int expected_refcnt;
expected_refcnt = rel->rd_isnailed ? 2 : 1;
if (rel->rd_refcnt != expected_refcnt)
ereport(ERROR,
(errcode(ERRCODE_OBJECT_IN_USE),
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
/* translator: first %s is a SQL command, eg ALTER TABLE */
Add checks to TRUNCATE, CLUSTER, and REINDEX to prevent performing these operations when the current transaction has any open references to the target relation or index (implying it has an active query using the relation). The need for this was previously recognized in connection with ALTER TABLE, but anything that summarily eliminates tuples or moves them around would confuse an active scan. While this patch does not in itself fix bug #3883 (the deadlock would happen before the new check fires), it will discourage people from attempting the sequence of operations that creates a deadlock risk, so it's at least a partial response to that problem. In passing, add a previously-missing check to REINDEX to prevent trying to reindex another backend's temp table. This isn't a security problem since only a superuser would get past the schema permission checks, but if we are testing for this in other utility commands then surely REINDEX should too.
2008-01-30 20:46:48 +01:00
errmsg("cannot %s \"%s\" because "
"it is being used by active queries in this session",
stmt, RelationGetRelationName(rel))));
if (rel->rd_rel->relkind != RELKIND_INDEX &&
AfterTriggerPendingOnRel(RelationGetRelid(rel)))
ereport(ERROR,
(errcode(ERRCODE_OBJECT_IN_USE),
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
/* translator: first %s is a SQL command, eg ALTER TABLE */
Add checks to TRUNCATE, CLUSTER, and REINDEX to prevent performing these operations when the current transaction has any open references to the target relation or index (implying it has an active query using the relation). The need for this was previously recognized in connection with ALTER TABLE, but anything that summarily eliminates tuples or moves them around would confuse an active scan. While this patch does not in itself fix bug #3883 (the deadlock would happen before the new check fires), it will discourage people from attempting the sequence of operations that creates a deadlock risk, so it's at least a partial response to that problem. In passing, add a previously-missing check to REINDEX to prevent trying to reindex another backend's temp table. This isn't a security problem since only a superuser would get past the schema permission checks, but if we are testing for this in other utility commands then surely REINDEX should too.
2008-01-30 20:46:48 +01:00
errmsg("cannot %s \"%s\" because "
"it has pending trigger events",
stmt, RelationGetRelationName(rel))));
}
Improve behavior of concurrent ALTER TABLE, and do some refactoring. ALTER TABLE (and ALTER VIEW, ALTER SEQUENCE, etc.) now use a RangeVarGetRelid callback to check permissions before acquiring a table lock. We also now use the same callback for all forms of ALTER TABLE, rather than having separate, almost-identical callbacks for ALTER TABLE .. SET SCHEMA and ALTER TABLE .. RENAME, and no callback at all for everything else. I went ahead and changed the code so that no form of ALTER TABLE works on foreign tables; you must use ALTER FOREIGN TABLE instead. In 9.1, it was possible to use ALTER TABLE .. SET SCHEMA or ALTER TABLE .. RENAME on a foreign table, but not any other form of ALTER TABLE, which did not seem terribly useful or consistent. Patch by me; review by Noah Misch.
2012-01-07 04:42:26 +01:00
/*
* AlterTableLookupRelation
* Look up, and lock, the OID for the relation named by an alter table
* statement.
*/
Oid
AlterTableLookupRelation(AlterTableStmt *stmt, LOCKMODE lockmode)
{
ALTER <thing> [IF EXISTS] ... allows silent DDL if required, e.g. ALTER FOREIGN TABLE IF EXISTS foo RENAME TO bar Pavel Stehule
2012-01-24 00:25:04 +01:00
return RangeVarGetRelidExtended(stmt->relation, lockmode, stmt->missing_ok, false,
Improve behavior of concurrent ALTER TABLE, and do some refactoring. ALTER TABLE (and ALTER VIEW, ALTER SEQUENCE, etc.) now use a RangeVarGetRelid callback to check permissions before acquiring a table lock. We also now use the same callback for all forms of ALTER TABLE, rather than having separate, almost-identical callbacks for ALTER TABLE .. SET SCHEMA and ALTER TABLE .. RENAME, and no callback at all for everything else. I went ahead and changed the code so that no form of ALTER TABLE works on foreign tables; you must use ALTER FOREIGN TABLE instead. In 9.1, it was possible to use ALTER TABLE .. SET SCHEMA or ALTER TABLE .. RENAME on a foreign table, but not any other form of ALTER TABLE, which did not seem terribly useful or consistent. Patch by me; review by Noah Misch.
2012-01-07 04:42:26 +01:00
RangeVarCallbackForAlterRelation,
(void *) stmt);
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* AlterTable
* Execute ALTER TABLE, which can be a list of subcommands
*
* ALTER TABLE is performed in three phases:
* 1. Examine subcommands and perform pre-transformation checking.
* 2. Update system catalogs.
* 3. Scan table(s) to check new constraints, and optionally recopy
* the data into new table(s).
* Phase 3 is not performed unless one or more of the subcommands requires
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
* it. The intention of this design is to allow multiple independent
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* updates of the table schema to be performed with only one pass over the
* data.
*
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
* ATPrepCmd performs phase 1. A "work queue" entry is created for
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* each table to be affected (there may be multiple affected tables if the
* commands traverse a table inheritance hierarchy). Also we do preliminary
* validation of the subcommands, including parse transformation of those
* expressions that need to be evaluated with respect to the old table
* schema.
*
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* ATRewriteCatalogs performs phase 2 for each affected table. (Note that
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
* phases 2 and 3 normally do no explicit recursion, since phase 1 already
* did it --- although some subcommands have to recurse in phase 2 instead.)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* Certain subcommands need to be performed before others to avoid
* unnecessary conflicts; for example, DROP COLUMN should come before
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
* ADD COLUMN. Therefore phase 1 divides the subcommands into multiple
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* lists, one for each logical "pass" of phase 2.
*
* ATRewriteTables performs phase 3 for those tables that need it.
*
* Thanks to the magic of MVCC, an error anywhere along the way rolls back
* the whole operation; we don't have to do anything special to clean up.
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
*
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* The caller must lock the relation, with an appropriate lock level
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
* for the subcommands requested. Any subcommand that needs to rewrite
* tuples in the table forces the whole command to be executed with
Improve behavior of concurrent ALTER TABLE, and do some refactoring. ALTER TABLE (and ALTER VIEW, ALTER SEQUENCE, etc.) now use a RangeVarGetRelid callback to check permissions before acquiring a table lock. We also now use the same callback for all forms of ALTER TABLE, rather than having separate, almost-identical callbacks for ALTER TABLE .. SET SCHEMA and ALTER TABLE .. RENAME, and no callback at all for everything else. I went ahead and changed the code so that no form of ALTER TABLE works on foreign tables; you must use ALTER FOREIGN TABLE instead. In 9.1, it was possible to use ALTER TABLE .. SET SCHEMA or ALTER TABLE .. RENAME on a foreign table, but not any other form of ALTER TABLE, which did not seem terribly useful or consistent. Patch by me; review by Noah Misch.
2012-01-07 04:42:26 +01:00
* AccessExclusiveLock (actually, that is currently required always, but
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* we hope to relax it at some point). We pass the lock level down
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
* so that we can apply it recursively to inherited tables. Note that the
Improve behavior of concurrent ALTER TABLE, and do some refactoring. ALTER TABLE (and ALTER VIEW, ALTER SEQUENCE, etc.) now use a RangeVarGetRelid callback to check permissions before acquiring a table lock. We also now use the same callback for all forms of ALTER TABLE, rather than having separate, almost-identical callbacks for ALTER TABLE .. SET SCHEMA and ALTER TABLE .. RENAME, and no callback at all for everything else. I went ahead and changed the code so that no form of ALTER TABLE works on foreign tables; you must use ALTER FOREIGN TABLE instead. In 9.1, it was possible to use ALTER TABLE .. SET SCHEMA or ALTER TABLE .. RENAME on a foreign table, but not any other form of ALTER TABLE, which did not seem terribly useful or consistent. Patch by me; review by Noah Misch.
2012-01-07 04:42:26 +01:00
* lock level we want as we recurse might well be higher than required for
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
* that specific subcommand. So we pass down the overall lock requirement,
* rather than reassess it at lower levels.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
void
Improve behavior of concurrent ALTER TABLE, and do some refactoring. ALTER TABLE (and ALTER VIEW, ALTER SEQUENCE, etc.) now use a RangeVarGetRelid callback to check permissions before acquiring a table lock. We also now use the same callback for all forms of ALTER TABLE, rather than having separate, almost-identical callbacks for ALTER TABLE .. SET SCHEMA and ALTER TABLE .. RENAME, and no callback at all for everything else. I went ahead and changed the code so that no form of ALTER TABLE works on foreign tables; you must use ALTER FOREIGN TABLE instead. In 9.1, it was possible to use ALTER TABLE .. SET SCHEMA or ALTER TABLE .. RENAME on a foreign table, but not any other form of ALTER TABLE, which did not seem terribly useful or consistent. Patch by me; review by Noah Misch.
2012-01-07 04:42:26 +01:00
AlterTable(Oid relid, LOCKMODE lockmode, AlterTableStmt *stmt)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
Relation rel;
Improve behavior of concurrent ALTER TABLE, and do some refactoring. ALTER TABLE (and ALTER VIEW, ALTER SEQUENCE, etc.) now use a RangeVarGetRelid callback to check permissions before acquiring a table lock. We also now use the same callback for all forms of ALTER TABLE, rather than having separate, almost-identical callbacks for ALTER TABLE .. SET SCHEMA and ALTER TABLE .. RENAME, and no callback at all for everything else. I went ahead and changed the code so that no form of ALTER TABLE works on foreign tables; you must use ALTER FOREIGN TABLE instead. In 9.1, it was possible to use ALTER TABLE .. SET SCHEMA or ALTER TABLE .. RENAME on a foreign table, but not any other form of ALTER TABLE, which did not seem terribly useful or consistent. Patch by me; review by Noah Misch.
2012-01-07 04:42:26 +01:00
/* Caller is required to provide an adequate lock. */
rel = relation_open(relid, NoLock);
Forbid ALTER TABLE and CLUSTER when there are pending AFTER-trigger events in the current backend for the target table. These operations move tuples around and would thus invalidate the TIDs stored in the trigger event records. (We need not worry about events in other backends, since acquiring exclusive lock should be enough to ensure there aren't any.) It might be sufficient to forbid only the table-rewriting variants of ALTER TABLE, but in the absence of any compelling use-case, let's just be safe and simple. Per follow-on investigation of bug #3847, though this is not actually the same problem reported therein. Possibly this should be back-patched, but since the case has never been reported from the field, I didn't bother.
2008-01-03 00:34:42 +01:00
Add checks to TRUNCATE, CLUSTER, and REINDEX to prevent performing these operations when the current transaction has any open references to the target relation or index (implying it has an active query using the relation). The need for this was previously recognized in connection with ALTER TABLE, but anything that summarily eliminates tuples or moves them around would confuse an active scan. While this patch does not in itself fix bug #3883 (the deadlock would happen before the new check fires), it will discourage people from attempting the sequence of operations that creates a deadlock risk, so it's at least a partial response to that problem. In passing, add a previously-missing check to REINDEX to prevent trying to reindex another backend's temp table. This isn't a security problem since only a superuser would get past the schema permission checks, but if we are testing for this in other utility commands then surely REINDEX should too.
2008-01-30 20:46:48 +01:00
CheckTableNotInUse(rel, "ALTER TABLE");
Forbid ALTER TABLE and CLUSTER when there are pending AFTER-trigger events in the current backend for the target table. These operations move tuples around and would thus invalidate the TIDs stored in the trigger event records. (We need not worry about events in other backends, since acquiring exclusive lock should be enough to ensure there aren't any.) It might be sufficient to forbid only the table-rewriting variants of ALTER TABLE, but in the absence of any compelling use-case, let's just be safe and simple. Per follow-on investigation of bug #3847, though this is not actually the same problem reported therein. Possibly this should be back-patched, but since the case has never been reported from the field, I didn't bother.
2008-01-03 00:34:42 +01:00
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATController(rel, stmt->cmds, interpretInhOption(stmt->relation->inhOpt),
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
lockmode);
Forbid ALTER TABLE and CLUSTER when there are pending AFTER-trigger events in the current backend for the target table. These operations move tuples around and would thus invalidate the TIDs stored in the trigger event records. (We need not worry about events in other backends, since acquiring exclusive lock should be enough to ensure there aren't any.) It might be sufficient to forbid only the table-rewriting variants of ALTER TABLE, but in the absence of any compelling use-case, let's just be safe and simple. Per follow-on investigation of bug #3847, though this is not actually the same problem reported therein. Possibly this should be back-patched, but since the case has never been reported from the field, I didn't bother.
2008-01-03 00:34:42 +01:00
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* AlterTableInternal
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* ALTER TABLE with target specified by OID
Repair failure to check that a table is still compatible with a previously 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
2007-02-02 01:07:03 +01:00
*
* We do not reject if the relation is already open, because it's quite
* likely that one or more layers of caller have it open. That means it
* is unsafe to use this entry point for alterations that could break
Forbid ALTER TABLE and CLUSTER when there are pending AFTER-trigger events in the current backend for the target table. These operations move tuples around and would thus invalidate the TIDs stored in the trigger event records. (We need not worry about events in other backends, since acquiring exclusive lock should be enough to ensure there aren't any.) It might be sufficient to forbid only the table-rewriting variants of ALTER TABLE, but in the absence of any compelling use-case, let's just be safe and simple. Per follow-on investigation of bug #3847, though this is not actually the same problem reported therein. Possibly this should be back-patched, but since the case has never been reported from the field, I didn't bother.
2008-01-03 00:34:42 +01:00
* existing query plans. On the assumption it's not used for such, we
* don't have to reject pending AFTER triggers, either.
TOAST WARNING: This is actually broken - we have self-deadlocks due to concurrent changes in buffer management. Vadim and me are working on it. Jan
2000-07-04 01:10:14 +02:00
*/
void
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
AlterTableInternal(Oid relid, List *cmds, bool recurse)
TOAST WARNING: This is actually broken - we have self-deadlocks due to concurrent changes in buffer management. Vadim and me are working on it. Jan
2000-07-04 01:10:14 +02:00
{
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
Relation rel;
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
LOCKMODE lockmode = AlterTableGetLockLevel(cmds);
Repair failure to check that a table is still compatible with a previously 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
2007-02-02 01:07:03 +01:00
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
rel = relation_open(relid, lockmode);
ATController(rel, cmds, recurse, lockmode);
}
/*
* AlterTableGetLockLevel
*
* Sets the overall lock level required for the supplied list of subcommands.
* Policy for doing this set according to needs of AlterTable(), see
* comments there for overall explanation.
*
* Function is called before and after parsing, so it must give same
* answer each time it is called. Some subcommands are transformed
* into other subcommand types, so the transform must never be made to a
* lower lock level than previously assigned. All transforms are noted below.
*
* Since this is called before we lock the table we cannot use table metadata
* to influence the type of lock we acquire.
*
* There should be no lockmodes hardcoded into the subcommand functions. All
* lockmode decisions for ALTER TABLE are made here only. The one exception is
* ALTER TABLE RENAME which is treated as a different statement type T_RenameStmt
* and does not travel through this section of code and cannot be combined with
* any of the subcommands given here.
*/
LOCKMODE
AlterTableGetLockLevel(List *cmds)
{
Reset ALTER TABLE lock levels to AccessExclusiveLock in all cases. Locks on inheritance parent remain at lower level, as they were before. Remove entry from 9.1 release notes.
2011-07-04 10:31:40 +02:00
/*
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* Late in 9.1 dev cycle a number of issues were uncovered with access to
* catalog relations, leading to the decision to re-enforce all DDL at
* AccessExclusiveLock level by default.
Reset ALTER TABLE lock levels to AccessExclusiveLock in all cases. Locks on inheritance parent remain at lower level, as they were before. Remove entry from 9.1 release notes.
2011-07-04 10:31:40 +02:00
*
* The issues are that there is a pervasive assumption in the code that
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* the catalogs will not be read unless an AccessExclusiveLock is held. If
* that rule is relaxed, we must protect against a number of potential
Reset ALTER TABLE lock levels to AccessExclusiveLock in all cases. Locks on inheritance parent remain at lower level, as they were before. Remove entry from 9.1 release notes.
2011-07-04 10:31:40 +02:00
* effects - infrequent, but proven possible with test cases where
* multiple DDL operations occur in a stream against frequently accessed
* tables.
*
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* 1. Catalog tables are read using SnapshotNow, which has a race bug that
* allows a scan to return no valid rows even when one is present in the
* case of a commit of a concurrent update of the catalog table.
* SnapshotNow also ignores transactions in progress, so takes the latest
* committed version without waiting for the latest changes.
Reset ALTER TABLE lock levels to AccessExclusiveLock in all cases. Locks on inheritance parent remain at lower level, as they were before. Remove entry from 9.1 release notes.
2011-07-04 10:31:40 +02:00
*
* 2. Relcache needs to be internally consistent, so unless we lock the
* definition during reads we have no way to guarantee that.
*
* 3. Catcache access isn't coordinated at all so refreshes can occur at
* any time.
*/
#ifdef REDUCED_ALTER_TABLE_LOCK_LEVELS
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ListCell *lcmd;
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
LOCKMODE lockmode = ShareUpdateExclusiveLock;
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
foreach(lcmd, cmds)
{
AlterTableCmd *cmd = (AlterTableCmd *) lfirst(lcmd);
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
LOCKMODE cmd_lockmode = AccessExclusiveLock; /* default for compiler */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
switch (cmd->subtype)
{
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
/*
* Need AccessExclusiveLock for these subcommands because they
* affect or potentially affect both read and write
* operations.
*
* New subcommand types should be added here by default.
*/
case AT_AddColumn: /* may rewrite heap, in some cases and visible
* to SELECT */
case AT_DropColumn: /* change visible to SELECT */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
case AT_AddColumnToView: /* CREATE VIEW */
case AT_AlterColumnType: /* must rewrite heap */
case AT_DropConstraint: /* as DROP INDEX */
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
case AT_AddOids: /* must rewrite heap */
case AT_DropOids: /* calls AT_DropColumn */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
case AT_EnableAlwaysRule: /* may change SELECT rules */
case AT_EnableReplicaRule: /* may change SELECT rules */
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
case AT_EnableRule: /* may change SELECT rules */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
case AT_DisableRule: /* may change SELECT rules */
case AT_ChangeOwner: /* change visible to SELECT */
case AT_SetTableSpace: /* must rewrite heap */
case AT_DropNotNull: /* may change some SQL plans */
case AT_SetNotNull:
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
case AT_GenericOptions:
Allow per-column foreign data wrapper options. Shigeru Hanada, with fairly minor editing by me.
2011-08-05 19:24:03 +02:00
case AT_AlterColumnGenericOptions:
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
cmd_lockmode = AccessExclusiveLock;
break;
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
/*
* These subcommands affect write operations only.
*/
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
case AT_ColumnDefault:
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
case AT_ProcessedConstraint: /* becomes AT_AddConstraint */
case AT_AddConstraintRecurse: /* becomes AT_AddConstraint */
pgindent run for release 9.3 This is the first run of the Perl-based pgindent script. Also update pgindent instructions.
2013-05-29 22:58:43 +02:00
case AT_ReAddConstraint: /* becomes AT_AddConstraint */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
case AT_EnableTrig:
case AT_EnableAlwaysTrig:
case AT_EnableReplicaTrig:
case AT_EnableTrigAll:
case AT_EnableTrigUser:
case AT_DisableTrig:
case AT_DisableTrigAll:
case AT_DisableTrigUser:
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
case AT_AddIndex: /* from ADD CONSTRAINT */
Implement ALTER TABLE ADD UNIQUE/PRIMARY KEY USING INDEX. This feature allows a unique or pkey constraint to be created using an already-existing unique index. While the constraint isn't very functionally different from the bare index, it's nice to be able to do that for documentation purposes. The main advantage over just issuing a plain ALTER TABLE ADD UNIQUE/PRIMARY KEY is that the index can be created with CREATE INDEX CONCURRENTLY, so that there is not a long interval where the table is locked against updates. On the way, refactor some of the code in DefineIndex() and index_create() so that we don't have to pass through those functions in order to create the index constraint's catalog entries. Also, in parse_utilcmd.c, pass around the ParseState pointer in struct CreateStmtContext to save on notation, and add error location pointers to some error reports that didn't have one before. Gurjeet Singh, reviewed by Steve Singer and Tom Lane
2011-01-25 21:42:03 +01:00
case AT_AddIndexConstraint:
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
cmd_lockmode = ShareRowExclusiveLock;
break;
case AT_AddConstraint:
if (IsA(cmd->def, Constraint))
{
Constraint *con = (Constraint *) cmd->def;
switch (con->contype)
{
case CONSTR_EXCLUSION:
case CONSTR_PRIMARY:
case CONSTR_UNIQUE:
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
/*
* Cases essentially the same as CREATE INDEX. We
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
* could reduce the lock strength to ShareLock if
* we can work out how to allow concurrent catalog
* updates.
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
*/
cmd_lockmode = ShareRowExclusiveLock;
break;
case CONSTR_FOREIGN:
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
/*
* We add triggers to both tables when we add a
* Foreign Key, so the lock level must be at least
* as strong as CREATE TRIGGER.
*/
cmd_lockmode = ShareRowExclusiveLock;
break;
default:
cmd_lockmode = ShareRowExclusiveLock;
}
}
break;
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
/*
* These subcommands affect inheritance behaviour. Queries
* started before us will continue to see the old inheritance
* behaviour, while queries started after we commit will see
* new behaviour. No need to prevent reads or writes to the
Remove obsolete comment. 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.
2011-04-14 04:20:39 +02:00
* subtable while we hook it up though.
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
*/
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
case AT_AddInherit:
case AT_DropInherit:
cmd_lockmode = ShareUpdateExclusiveLock;
break;
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
/*
* These subcommands affect implicit row type conversion. They
* have affects similar to CREATE/DROP CAST on queries. We
* don't provide for invalidating parse trees as a result of
Pgindent run before 9.1 beta2.
2011-06-09 20:32:50 +02:00
* such changes. Do avoid concurrent pg_class updates,
* though.
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
*/
case AT_AddOf:
case AT_DropOf:
cmd_lockmode = ShareUpdateExclusiveLock;
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
/*
* These subcommands affect general strategies for performance
* and maintenance, though don't change the semantic results
* from normal data reads and writes. Delaying an ALTER TABLE
* behind currently active writes only delays the point where
* the new strategy begins to take effect, so there is no
* benefit in waiting. In this case the minimum restriction
* applies: we don't currently allow concurrent catalog
* updates.
*/
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
case AT_SetStatistics:
case AT_ClusterOn:
case AT_DropCluster:
case AT_SetRelOptions:
case AT_ResetRelOptions:
Add a security_barrier option for views. When a view is marked as a security barrier, it will not be pulled up into the containing query, and no quals will be pushed down into it, so that no function or operator chosen by the user can be applied to rows not exposed by the view. Views not configured with this option cannot provide robust row-level security, but will perform far better. Patch by KaiGai Kohei; original problem report by Heikki Linnakangas (in October 2009!). Review (in earlier versions) by Noah Misch and others. Design advice by Tom Lane and myself. Further review and cleanup by me.
2011-12-22 22:15:57 +01:00
case AT_ReplaceRelOptions:
Add explicit regression tests for ALTER TABLE lock levels. Use this to catch a couple of lock level assignments that slipped through manual testing, per Peter Eisentraut.
2010-07-29 13:06:34 +02:00
case AT_SetOptions:
case AT_ResetOptions:
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
case AT_SetStorage:
Extend ALTER TABLE to allow Foreign Keys to be added without initial validation. 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
2011-02-08 13:23:20 +01:00
case AT_ValidateConstraint:
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
cmd_lockmode = ShareUpdateExclusiveLock;
break;
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
default: /* oops */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
elog(ERROR, "unrecognized alter table type: %d",
(int) cmd->subtype);
break;
}
/*
* Take the greatest lockmode from any subcommand
*/
if (cmd_lockmode > lockmode)
lockmode = cmd_lockmode;
}
Reset ALTER TABLE lock levels to AccessExclusiveLock in all cases. Locks on inheritance parent remain at lower level, as they were before. Remove entry from 9.1 release notes.
2011-07-04 10:31:40 +02:00
#else
LOCKMODE lockmode = AccessExclusiveLock;
#endif
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
return lockmode;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
TOAST WARNING: This is actually broken - we have self-deadlocks due to concurrent changes in buffer management. Vadim and me are working on it. Jan
2000-07-04 01:10:14 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static void
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATController(Relation rel, List *cmds, bool recurse, LOCKMODE lockmode)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
List *wqueue = NIL;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *lcmd;
Clean up checking of relkind for ALTER TABLE and LOCK TABLE commands. Disallow cases like adding constraints to sequences :-(, and eliminate now-unnecessary search of pg_rewrite to decide if a relation is a view.
2001-01-07 01:05:22 +01:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Phase 1: preliminary examination of commands, create work queue */
foreach(lcmd, cmds)
{
AlterTableCmd *cmd = (AlterTableCmd *) lfirst(lcmd);
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATPrepCmd(&wqueue, rel, cmd, recurse, false, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
/* Close the relation, but keep lock until commit */
relation_close(rel, NoLock);
/* Phase 2: update system catalogs */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATRewriteCatalogs(&wqueue, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Phase 3: scan/rewrite tables as needed */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATRewriteTables(&wqueue, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
/*
* ATPrepCmd
*
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
* Traffic cop for ALTER TABLE Phase 1 operations, including simple
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* recursion and permission checks.
*
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
* Caller must have acquired appropriate lock type on relation already.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* This lock should be held until commit.
*/
static void
ATPrepCmd(List **wqueue, Relation rel, AlterTableCmd *cmd,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
bool recurse, bool recursing, LOCKMODE lockmode)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
AlteredTableInfo *tab;
int pass;
/* Find or create work queue entry for this table */
tab = ATGetQueueEntry(wqueue, rel);
Clean up checking of relkind for ALTER TABLE and LOCK TABLE commands. Disallow cases like adding constraints to sequences :-(, and eliminate now-unnecessary search of pg_rewrite to decide if a relation is a view.
2001-01-07 01:05:22 +01:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* Copy the original subcommand for each table. This avoids conflicts
* when different child tables need to make different parse
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* transformations (for example, the same column may have different column
* numbers in different children).
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
cmd = copyObject(cmd);
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
Avoid creating a TOAST table if we can prove that the maximum tuple length is < TOAST_TUPLE_THRESHOLD, even with toastable column types present. For example, CREATE TABLE foo (f1 int, f2 varchar(100)) does not require a toast table, even though varchar is a toastable type.
2000-08-25 20:05:54 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Do permissions checking, recursion to child tables if needed, and any
* additional phase-1 processing needed.
Bugfix in ALTER TABLE CREATE TOAST TABLE Automatically create toast table at CREATE TABLE if new table has toastable attributes. Jan
2000-07-05 14:45:31 +02:00
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
switch (cmd->subtype)
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
{
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
case AT_AddColumn: /* ADD COLUMN */
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
ATSimplePermissions(rel,
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
ATT_TABLE | ATT_COMPOSITE_TYPE | ATT_FOREIGN_TABLE);
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
ATPrepAddColumn(wqueue, rel, recurse, recursing, cmd, lockmode);
Rearrange "add column" logic to merge columns at exec time. 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.
2011-04-04 03:52:47 +02:00
/* Recursion occurs during execution phase */
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
pass = AT_PASS_ADD_COL;
break;
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
case AT_AddColumnToView: /* add column via CREATE OR REPLACE
* VIEW */
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
ATSimplePermissions(rel, ATT_VIEW);
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
ATPrepAddColumn(wqueue, rel, recurse, recursing, cmd, lockmode);
Rearrange "add column" logic to merge columns at exec time. 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.
2011-04-04 03:52:47 +02:00
/* Recursion occurs during execution phase */
Allow CREATE OR REPLACE VIEW to add columns to the _end_ of the view. Robert Haas
2008-12-07 00:22:46 +01:00
pass = AT_PASS_ADD_COL;
break;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
case AT_ColumnDefault: /* ALTER COLUMN DEFAULT */
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* We allow defaults on views so that INSERT into a view can have
* default-ish behavior. This works because the rewriter
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* substitutes default values into INSERTs before it expands
* rules.
*/
Allow default expressions to be attached to columns of foreign tables. There's still some discussion about exactly how postgres_fdw ought to handle this case, but there seems no debate that we want to allow defaults to be used for inserts into foreign tables. So remove the core-code restrictions that prevented it. While at it, get rid of the special grammar productions for CREATE FOREIGN TABLE, and instead add explicit FEATURE_NOT_SUPPORTED error checks for the disallowed cases. This makes the grammar a shade smaller, and more importantly results in much more intelligible error messages for unsupported cases. It's also one less thing to fix if we ever start supporting constraints on foreign tables.
2013-03-12 22:37:07 +01:00
ATSimplePermissions(rel, ATT_TABLE | ATT_VIEW | ATT_FOREIGN_TABLE);
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATSimpleRecursion(wqueue, rel, cmd, recurse, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* No command-specific prep needed */
Cause ALTER TABLE to perform ALTER COLUMN DROP DEFAULT operations during 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.
2006-08-03 22:57:06 +02:00
pass = cmd->def ? AT_PASS_ADD_CONSTR : AT_PASS_DROP;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
break;
case AT_DropNotNull: /* ALTER COLUMN DROP NOT NULL */
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
ATSimplePermissions(rel, ATT_TABLE | ATT_FOREIGN_TABLE);
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATSimpleRecursion(wqueue, rel, cmd, recurse, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* No command-specific prep needed */
pass = AT_PASS_DROP;
break;
case AT_SetNotNull: /* ALTER COLUMN SET NOT NULL */
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
ATSimplePermissions(rel, ATT_TABLE | ATT_FOREIGN_TABLE);
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATSimpleRecursion(wqueue, rel, cmd, recurse, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* No command-specific prep needed */
pass = AT_PASS_ADD_CONSTR;
break;
Add ALTER TABLE ... ALTER COLUMN ... SET STATISTICS DISTINCT Robert Haas
2009-08-03 00:14:53 +02:00
case AT_SetStatistics: /* ALTER COLUMN SET STATISTICS */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATSimpleRecursion(wqueue, rel, cmd, recurse, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Performs own permission checks */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATPrepSetStatistics(rel, cmd->name, cmd->def, lockmode);
Add explicit regression tests for ALTER TABLE lock levels. Use this to catch a couple of lock level assignments that slipped through manual testing, per Peter Eisentraut.
2010-07-29 13:06:34 +02:00
pass = AT_PASS_MISC;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
break;
Replace ALTER TABLE ... SET STATISTICS DISTINCT with a more general mechanism. Attributes can now have options, just as relations and tablespaces do, and the reloptions code is used to parse, validate, and store them. For simplicity and because these options are not performance critical, we store them in a separate cache rather than the main relcache. Thanks to Alex Hunsaker for the review.
2010-01-22 17:40:19 +01:00
case AT_SetOptions: /* ALTER COLUMN SET ( options ) */
case AT_ResetOptions: /* ALTER COLUMN RESET ( options ) */
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
ATSimplePermissions(rel, ATT_TABLE | ATT_MATVIEW | ATT_INDEX | ATT_FOREIGN_TABLE);
Replace ALTER TABLE ... SET STATISTICS DISTINCT with a more general mechanism. Attributes can now have options, just as relations and tablespaces do, and the reloptions code is used to parse, validate, and store them. For simplicity and because these options are not performance critical, we store them in a separate cache rather than the main relcache. Thanks to Alex Hunsaker for the review.
2010-01-22 17:40:19 +01:00
/* This command never recurses */
Add explicit regression tests for ALTER TABLE lock levels. Use this to catch a couple of lock level assignments that slipped through manual testing, per Peter Eisentraut.
2010-07-29 13:06:34 +02:00
pass = AT_PASS_MISC;
Add ALTER TABLE ... ALTER COLUMN ... SET STATISTICS DISTINCT Robert Haas
2009-08-03 00:14:53 +02:00
break;
case AT_SetStorage: /* ALTER COLUMN SET STORAGE */
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
ATSimplePermissions(rel, ATT_TABLE | ATT_MATVIEW);
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATSimpleRecursion(wqueue, rel, cmd, recurse, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* No command-specific prep needed */
Add explicit regression tests for ALTER TABLE lock levels. Use this to catch a couple of lock level assignments that slipped through manual testing, per Peter Eisentraut.
2010-07-29 13:06:34 +02:00
pass = AT_PASS_MISC;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
break;
case AT_DropColumn: /* DROP COLUMN */
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
ATSimplePermissions(rel,
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
ATT_TABLE | ATT_COMPOSITE_TYPE | ATT_FOREIGN_TABLE);
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
ATPrepDropColumn(wqueue, rel, recurse, recursing, cmd, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Recursion occurs during execution phase */
pass = AT_PASS_DROP;
break;
case AT_AddIndex: /* ADD INDEX */
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
ATSimplePermissions(rel, ATT_TABLE | ATT_MATVIEW);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* This command never recurses */
/* No command-specific prep needed */
pass = AT_PASS_ADD_INDEX;
break;
case AT_AddConstraint: /* ADD CONSTRAINT */
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
ATSimplePermissions(rel, ATT_TABLE);
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
/* Recursion occurs during execution phase */
/* No command-specific prep needed except saving recurse flag */
if (recurse)
cmd->subtype = AT_AddConstraintRecurse;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
pass = AT_PASS_ADD_CONSTR;
break;
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
case AT_AddIndexConstraint: /* ADD CONSTRAINT USING INDEX */
Implement ALTER TABLE ADD UNIQUE/PRIMARY KEY USING INDEX. This feature allows a unique or pkey constraint to be created using an already-existing unique index. While the constraint isn't very functionally different from the bare index, it's nice to be able to do that for documentation purposes. The main advantage over just issuing a plain ALTER TABLE ADD UNIQUE/PRIMARY KEY is that the index can be created with CREATE INDEX CONCURRENTLY, so that there is not a long interval where the table is locked against updates. On the way, refactor some of the code in DefineIndex() and index_create() so that we don't have to pass through those functions in order to create the index constraint's catalog entries. Also, in parse_utilcmd.c, pass around the ParseState pointer in struct CreateStmtContext to save on notation, and add error location pointers to some error reports that didn't have one before. Gurjeet Singh, reviewed by Steve Singer and Tom Lane
2011-01-25 21:42:03 +01:00
ATSimplePermissions(rel, ATT_TABLE);
/* This command never recurses */
/* No command-specific prep needed */
pass = AT_PASS_ADD_CONSTR;
break;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
case AT_DropConstraint: /* DROP CONSTRAINT */
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
ATSimplePermissions(rel, ATT_TABLE);
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
/* Recursion occurs during execution phase */
/* No command-specific prep needed except saving recurse flag */
if (recurse)
cmd->subtype = AT_DropConstraintRecurse;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
pass = AT_PASS_DROP;
break;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
case AT_AlterColumnType: /* ALTER COLUMN TYPE */
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
ATSimplePermissions(rel,
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
ATT_TABLE | ATT_COMPOSITE_TYPE | ATT_FOREIGN_TABLE);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Performs own recursion */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATPrepAlterColumnType(wqueue, tab, rel, recurse, recursing, cmd, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
pass = AT_PASS_ALTER_TYPE;
break;
Allow per-column foreign data wrapper options. Shigeru Hanada, with fairly minor editing by me.
2011-08-05 19:24:03 +02:00
case AT_AlterColumnGenericOptions:
ATSimplePermissions(rel, ATT_FOREIGN_TABLE);
/* This command never recurses */
/* No command-specific prep needed */
pass = AT_PASS_MISC;
break;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
case AT_ChangeOwner: /* ALTER OWNER */
/* This command never recurses */
/* No command-specific prep needed */
pass = AT_PASS_MISC;
break;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
case AT_ClusterOn: /* CLUSTER ON */
OK, here's the final version of ALTER TABLE ... SET WITHOUT CLUSTER. Has docs + regression test. Christopher Kings-Lynne
2004-06-02 23:01:10 +02:00
case AT_DropCluster: /* SET WITHOUT CLUSTER */
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
ATSimplePermissions(rel, ATT_TABLE | ATT_MATVIEW);
OK, here's the final version of ALTER TABLE ... SET WITHOUT CLUSTER. Has docs + regression test. Christopher Kings-Lynne
2004-06-02 23:01:10 +02:00
/* These commands never recurse */
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* No command-specific prep needed */
pass = AT_PASS_MISC;
break;
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
case AT_AddOids: /* SET WITH OIDS */
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
ATSimplePermissions(rel, ATT_TABLE);
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
if (!rel->rd_rel->relhasoids || recursing)
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATPrepAddOids(wqueue, rel, recurse, cmd, lockmode);
Rearrange "add column" logic to merge columns at exec time. 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.
2011-04-04 03:52:47 +02:00
/* Recursion occurs during execution phase */
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
pass = AT_PASS_ADD_COL;
break;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
case AT_DropOids: /* SET WITHOUT OIDS */
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
ATSimplePermissions(rel, ATT_TABLE);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Performs own recursion */
if (rel->rd_rel->relhasoids)
{
AlterTableCmd *dropCmd = makeNode(AlterTableCmd);
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
dropCmd->subtype = AT_DropColumn;
dropCmd->name = pstrdup("oid");
dropCmd->behavior = cmd->behavior;
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATPrepCmd(wqueue, rel, dropCmd, recurse, false, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
pass = AT_PASS_DROP;
break;
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
case AT_SetTableSpace: /* SET TABLESPACE */
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
ATSimplePermissions(rel, ATT_TABLE | ATT_MATVIEW | ATT_INDEX);
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
/* This command never recurses */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATPrepSetTableSpace(tab, rel, cmd->name, lockmode);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
pass = AT_PASS_MISC; /* doesn't actually matter */
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
break;
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
case AT_SetRelOptions: /* SET (...) */
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
case AT_ResetRelOptions: /* RESET (...) */
case AT_ReplaceRelOptions: /* reset them all, then set just these */
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
ATSimplePermissions(rel, ATT_TABLE | ATT_VIEW | ATT_MATVIEW | ATT_INDEX);
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
/* This command never recurses */
/* No command-specific prep needed */
pass = AT_PASS_MISC;
break;
Add more checks against altering typed tables - Prohibit altering column type - Prohibit changing inheritance - Move checks from Exec to Prep phases in ALTER TABLE code backpatched to 9.0
2010-07-23 22:04:18 +02:00
case AT_AddInherit: /* INHERIT */
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
ATSimplePermissions(rel, ATT_TABLE);
Add more checks against altering typed tables - Prohibit altering column type - Prohibit changing inheritance - Move checks from Exec to Prep phases in ALTER TABLE code backpatched to 9.0
2010-07-23 22:04:18 +02:00
/* This command never recurses */
ATPrepAddInherit(rel);
pass = AT_PASS_MISC;
break;
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
case AT_ValidateConstraint: /* VALIDATE CONSTRAINT */
ATSimplePermissions(rel, ATT_TABLE);
/* Recursion occurs during execution phase */
/* No command-specific prep needed except saving recurse flag */
if (recurse)
cmd->subtype = AT_ValidateConstraintRecurse;
pass = AT_PASS_MISC;
break;
Add ALTER TABLE ENABLE/DISABLE TRIGGER commands. Change pg_dump to use these instead of its previous hack of changing pg_class.reltriggers. Documentation is lacking, will add that later. Patch by Satoshi Nagayasu, review and some extra work by Tom Lane.
2005-08-24 00:40:47 +02:00
case AT_EnableTrig: /* ENABLE TRIGGER variants */
Changes pg_trigger and extend pg_rewrite in order to allow triggers and 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
2007-03-20 00:38:32 +01:00
case AT_EnableAlwaysTrig:
case AT_EnableReplicaTrig:
Add ALTER TABLE ENABLE/DISABLE TRIGGER commands. Change pg_dump to use these instead of its previous hack of changing pg_class.reltriggers. Documentation is lacking, will add that later. Patch by Satoshi Nagayasu, review and some extra work by Tom Lane.
2005-08-24 00:40:47 +02:00
case AT_EnableTrigAll:
case AT_EnableTrigUser:
case AT_DisableTrig: /* DISABLE TRIGGER variants */
case AT_DisableTrigAll:
case AT_DisableTrigUser:
Changes pg_trigger and extend pg_rewrite in order to allow triggers and 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
2007-03-20 00:38:32 +01:00
case AT_EnableRule: /* ENABLE/DISABLE RULE variants */
case AT_EnableAlwaysRule:
case AT_EnableReplicaRule:
case AT_DisableRule:
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
case AT_DropInherit: /* NO INHERIT */
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
case AT_AddOf: /* OF */
Pgindent run before 9.1 beta2.
2011-06-09 20:32:50 +02:00
case AT_DropOf: /* NOT OF */
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
ATSimplePermissions(rel, ATT_TABLE);
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
/* These commands never recurse */
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
/* No command-specific prep needed */
pass = AT_PASS_MISC;
break;
case AT_GenericOptions:
ATSimplePermissions(rel, ATT_FOREIGN_TABLE);
/* No command-specific prep needed */
pass = AT_PASS_MISC;
break;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
default: /* oops */
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
elog(ERROR, "unrecognized alter table type: %d",
(int) cmd->subtype);
pass = 0; /* keep compiler quiet */
break;
}
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Add the subcommand to the appropriate list for phase 2 */
tab->subcmds[pass] = lappend(tab->subcmds[pass], cmd);
}
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* ATRewriteCatalogs
*
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
* Traffic cop for ALTER TABLE Phase 2 operations. Subcommands are
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* dispatched in a "safe" execution order (designed to avoid unnecessary
* conflicts).
*/
static void
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATRewriteCatalogs(List **wqueue, LOCKMODE lockmode)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
int pass;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *ltab;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* We process all the tables "in parallel", one pass at a time. This is
* needed because we may have to propagate work from one table to another
* (specifically, ALTER TYPE on a foreign key's PK has to dispatch the
* re-adding of the foreign key constraint to the other table). Work can
* only be propagated into later passes, however.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
for (pass = 0; pass < AT_NUM_PASSES; pass++)
{
/* Go through each table that needs to be processed */
foreach(ltab, *wqueue)
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
{
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
AlteredTableInfo *tab = (AlteredTableInfo *) lfirst(ltab);
List *subcmds = tab->subcmds[pass];
Relation rel;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *lcmd;
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (subcmds == NIL)
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
continue;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
/*
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
* Appropriate lock was obtained by phase 1, needn't get it again
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
rel = relation_open(tab->relid, NoLock);
Code review for recent patch to allow ALTER TABLE ADD COLUMN when a child table already has a matching column. Acquire appropriate lock on child table; do the right thing with any CHECK constraints attached to the new parent column.
2002-11-02 23:02:08 +01:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
foreach(lcmd, subcmds)
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecCmd(wqueue, tab, rel, (AlterTableCmd *) lfirst(lcmd), lockmode);
Code review for recent patch to allow ALTER TABLE ADD COLUMN when a child table already has a matching column. Acquire appropriate lock on child table; do the right thing with any CHECK constraints attached to the new parent column.
2002-11-02 23:02:08 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* After the ALTER TYPE pass, do cleanup work (this is not done in
* ATExecAlterColumnType since it should be done only once if
* multiple columns of a table are altered).
Code review for recent patch to allow ALTER TABLE ADD COLUMN when a child table already has a matching column. Acquire appropriate lock on child table; do the right thing with any CHECK constraints attached to the new parent column.
2002-11-02 23:02:08 +01:00
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (pass == AT_PASS_ALTER_TYPE)
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATPostAlterTypeCleanup(wqueue, tab, lockmode);
Fix ALTER TABLE ... ADD COLUMN for inheritance cases. Alvaro Herrera
2002-10-21 22:31:52 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
relation_close(rel, NoLock);
}
}
Fix ALTER TABLE ... ADD COLUMN for inheritance cases. Alvaro Herrera
2002-10-21 22:31:52 +02:00
Fix toast table creation. 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
2011-04-14 03:07:14 +02:00
/* Check to see if a toast table must be added. */
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
foreach(ltab, *wqueue)
{
AlteredTableInfo *tab = (AlteredTableInfo *) lfirst(ltab);
Code review for recent patch to allow ALTER TABLE ADD COLUMN when a child table already has a matching column. Acquire appropriate lock on child table; do the right thing with any CHECK constraints attached to the new parent column.
2002-11-02 23:02:08 +01:00
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
if (tab->relkind == RELKIND_RELATION ||
tab->relkind == RELKIND_MATVIEW)
Preserve relfilenodes: Add support to pg_dump --binary-upgrade to preserve all relfilenodes, for use by pg_migrator.
2010-01-06 04:04:03 +01:00
AlterTableCreateToastTable(tab->relid, (Datum) 0);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
/*
* ATExecCmd: dispatch a subcommand to appropriate execution routine
*/
static void
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
ATExecCmd(List **wqueue, AlteredTableInfo *tab, Relation rel,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
AlterTableCmd *cmd, LOCKMODE lockmode)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
switch (cmd->subtype)
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
{
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
case AT_AddColumn: /* ADD COLUMN */
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
case AT_AddColumnToView: /* add column via CREATE OR REPLACE
* VIEW */
Rearrange "add column" logic to merge columns at exec time. 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.
2011-04-04 03:52:47 +02:00
ATExecAddColumn(wqueue, tab, rel, (ColumnDef *) cmd->def,
false, false, false, lockmode);
break;
case AT_AddColumnRecurse:
ATExecAddColumn(wqueue, tab, rel, (ColumnDef *) cmd->def,
false, true, false, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
break;
case AT_ColumnDefault: /* ALTER COLUMN DEFAULT */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecColumnDefault(rel, cmd->name, cmd->def, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
break;
case AT_DropNotNull: /* ALTER COLUMN DROP NOT NULL */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecDropNotNull(rel, cmd->name, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
break;
case AT_SetNotNull: /* ALTER COLUMN SET NOT NULL */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecSetNotNull(tab, rel, cmd->name, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
break;
Add ALTER TABLE ... ALTER COLUMN ... SET STATISTICS DISTINCT Robert Haas
2009-08-03 00:14:53 +02:00
case AT_SetStatistics: /* ALTER COLUMN SET STATISTICS */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecSetStatistics(rel, cmd->name, cmd->def, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
break;
Replace ALTER TABLE ... SET STATISTICS DISTINCT with a more general mechanism. Attributes can now have options, just as relations and tablespaces do, and the reloptions code is used to parse, validate, and store them. For simplicity and because these options are not performance critical, we store them in a separate cache rather than the main relcache. Thanks to Alex Hunsaker for the review.
2010-01-22 17:40:19 +01:00
case AT_SetOptions: /* ALTER COLUMN SET ( options ) */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecSetOptions(rel, cmd->name, cmd->def, false, lockmode);
Replace ALTER TABLE ... SET STATISTICS DISTINCT with a more general mechanism. Attributes can now have options, just as relations and tablespaces do, and the reloptions code is used to parse, validate, and store them. For simplicity and because these options are not performance critical, we store them in a separate cache rather than the main relcache. Thanks to Alex Hunsaker for the review.
2010-01-22 17:40:19 +01:00
break;
case AT_ResetOptions: /* ALTER COLUMN RESET ( options ) */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecSetOptions(rel, cmd->name, cmd->def, true, lockmode);
Add ALTER TABLE ... ALTER COLUMN ... SET STATISTICS DISTINCT Robert Haas
2009-08-03 00:14:53 +02:00
break;
case AT_SetStorage: /* ALTER COLUMN SET STORAGE */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecSetStorage(rel, cmd->name, cmd->def, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
break;
case AT_DropColumn: /* DROP COLUMN */
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
ATExecDropColumn(wqueue, rel, cmd->name,
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
cmd->behavior, false, false, cmd->missing_ok, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
break;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
case AT_DropColumnRecurse: /* DROP COLUMN with recursion */
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
ATExecDropColumn(wqueue, rel, cmd->name,
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
cmd->behavior, true, false, cmd->missing_ok, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
break;
case AT_AddIndex: /* ADD INDEX */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecAddIndex(tab, rel, (IndexStmt *) cmd->def, false, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
break;
case AT_ReAddIndex: /* ADD INDEX */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecAddIndex(tab, rel, (IndexStmt *) cmd->def, true, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
break;
case AT_AddConstraint: /* ADD CONSTRAINT */
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
ATExecAddConstraint(wqueue, tab, rel, (Constraint *) cmd->def,
Fix handling of inherited check constraints in ALTER COLUMN TYPE. This case got broken in 8.4 by the addition of an error check that complains if ALTER TABLE ONLY is used on a table that has children. We do use ONLY for this situation, but it's okay because the necessary recursion occurs at a higher level. So we need to have a separate flag to suppress recursion without making the error check. Reported and patched by Pavan Deolasee, with some editorial adjustments by me. Back-patch to 8.4, since this is a regression of functionality that worked in earlier branches.
2012-11-05 19:36:16 +01:00
false, false, lockmode);
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
break;
case AT_AddConstraintRecurse: /* ADD CONSTRAINT with recursion */
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
ATExecAddConstraint(wqueue, tab, rel, (Constraint *) cmd->def,
Fix handling of inherited check constraints in ALTER COLUMN TYPE. This case got broken in 8.4 by the addition of an error check that complains if ALTER TABLE ONLY is used on a table that has children. We do use ONLY for this situation, but it's okay because the necessary recursion occurs at a higher level. So we need to have a separate flag to suppress recursion without making the error check. Reported and patched by Pavan Deolasee, with some editorial adjustments by me. Back-patch to 8.4, since this is a regression of functionality that worked in earlier branches.
2012-11-05 19:36:16 +01:00
true, false, lockmode);
break;
pgindent run for release 9.3 This is the first run of the Perl-based pgindent script. Also update pgindent instructions.
2013-05-29 22:58:43 +02:00
case AT_ReAddConstraint: /* Re-add pre-existing check
* constraint */
Fix handling of inherited check constraints in ALTER COLUMN TYPE. This case got broken in 8.4 by the addition of an error check that complains if ALTER TABLE ONLY is used on a table that has children. We do use ONLY for this situation, but it's okay because the necessary recursion occurs at a higher level. So we need to have a separate flag to suppress recursion without making the error check. Reported and patched by Pavan Deolasee, with some editorial adjustments by me. Back-patch to 8.4, since this is a regression of functionality that worked in earlier branches.
2012-11-05 19:36:16 +01:00
ATExecAddConstraint(wqueue, tab, rel, (Constraint *) cmd->def,
false, true, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
break;
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
case AT_AddIndexConstraint: /* ADD CONSTRAINT USING INDEX */
Implement ALTER TABLE ADD UNIQUE/PRIMARY KEY USING INDEX. This feature allows a unique or pkey constraint to be created using an already-existing unique index. While the constraint isn't very functionally different from the bare index, it's nice to be able to do that for documentation purposes. The main advantage over just issuing a plain ALTER TABLE ADD UNIQUE/PRIMARY KEY is that the index can be created with CREATE INDEX CONCURRENTLY, so that there is not a long interval where the table is locked against updates. On the way, refactor some of the code in DefineIndex() and index_create() so that we don't have to pass through those functions in order to create the index constraint's catalog entries. Also, in parse_utilcmd.c, pass around the ParseState pointer in struct CreateStmtContext to save on notation, and add error location pointers to some error reports that didn't have one before. Gurjeet Singh, reviewed by Steve Singer and Tom Lane
2011-01-25 21:42:03 +01:00
ATExecAddIndexConstraint(tab, rel, (IndexStmt *) cmd->def, lockmode);
break;
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
case AT_ValidateConstraint: /* VALIDATE CONSTRAINT */
ATExecValidateConstraint(rel, cmd->name, false, false, lockmode);
break;
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
case AT_ValidateConstraintRecurse: /* VALIDATE CONSTRAINT with
* recursion */
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
ATExecValidateConstraint(rel, cmd->name, true, false, lockmode);
Extend ALTER TABLE to allow Foreign Keys to be added without initial validation. 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
2011-02-08 13:23:20 +01:00
break;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
case AT_DropConstraint: /* DROP CONSTRAINT */
DROP IF EXISTS for columns and constraints. Andres Freund.
2009-07-20 04:42:28 +02:00
ATExecDropConstraint(rel, cmd->name, cmd->behavior,
false, false,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
cmd->missing_ok, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
break;
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
case AT_DropConstraintRecurse: /* DROP CONSTRAINT with recursion */
DROP IF EXISTS for columns and constraints. Andres Freund.
2009-07-20 04:42:28 +02:00
ATExecDropConstraint(rel, cmd->name, cmd->behavior,
true, false,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
cmd->missing_ok, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
break;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
case AT_AlterColumnType: /* ALTER COLUMN TYPE */
Remove collation information from TypeName, where it does not belong. 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.
2011-03-10 04:38:52 +01:00
ATExecAlterColumnType(tab, rel, cmd, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
break;
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
case AT_AlterColumnGenericOptions: /* ALTER COLUMN OPTIONS */
Allow per-column foreign data wrapper options. Shigeru Hanada, with fairly minor editing by me.
2011-08-05 19:24:03 +02:00
ATExecAlterColumnGenericOptions(rel, cmd->name, (List *) cmd->def, lockmode);
break;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
case AT_ChangeOwner: /* ALTER OWNER */
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
ATExecChangeOwner(RelationGetRelid(rel),
Standardize get_whatever_oid functions for object types with unqualified names. - Add a missing_ok parameter to get_tablespace_oid. - Avoid duplicating get_tablespace_od guts in objectNamesToOids. - Add a missing_ok parameter to get_database_oid. - Replace get_roleid and get_role_checked with get_role_oid. - Add get_namespace_oid, get_language_oid, get_am_oid. - Refactor existing code to use new interfaces. Thanks to KaiGai Kohei for the review.
2010-08-05 16:45:09 +02:00
get_role_oid(cmd->name, false),
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
false, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
break;
case AT_ClusterOn: /* CLUSTER ON */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecClusterOn(rel, cmd->name, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
break;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
case AT_DropCluster: /* SET WITHOUT CLUSTER */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecDropCluster(rel, lockmode);
OK, here's the final version of ALTER TABLE ... SET WITHOUT CLUSTER. Has docs + regression test. Christopher Kings-Lynne
2004-06-02 23:01:10 +02:00
break;
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
case AT_AddOids: /* SET WITH OIDS */
/* Use the ADD COLUMN code, unless prep decided to do nothing */
if (cmd->def != NULL)
Rearrange "add column" logic to merge columns at exec time. 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.
2011-04-04 03:52:47 +02:00
ATExecAddColumn(wqueue, tab, rel, (ColumnDef *) cmd->def,
true, false, false, lockmode);
break;
case AT_AddOidsRecurse: /* SET WITH OIDS */
/* Use the ADD COLUMN code, unless prep decided to do nothing */
if (cmd->def != NULL)
ATExecAddColumn(wqueue, tab, rel, (ColumnDef *) cmd->def,
true, true, false, lockmode);
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
break;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
case AT_DropOids: /* SET WITHOUT OIDS */
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
* Nothing to do here; we'll have generated a DropColumn
* subcommand to do the real work
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
break;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
case AT_SetTableSpace: /* SET TABLESPACE */
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
/*
* Nothing to do here; Phase 3 does the work
*/
break;
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
case AT_SetRelOptions: /* SET (...) */
case AT_ResetRelOptions: /* RESET (...) */
Add a security_barrier option for views. When a view is marked as a security barrier, it will not be pulled up into the containing query, and no quals will be pushed down into it, so that no function or operator chosen by the user can be applied to rows not exposed by the view. Views not configured with this option cannot provide robust row-level security, but will perform far better. Patch by KaiGai Kohei; original problem report by Heikki Linnakangas (in October 2009!). Review (in earlier versions) by Noah Misch and others. Design advice by Tom Lane and myself. Further review and cleanup by me.
2011-12-22 22:15:57 +01:00
case AT_ReplaceRelOptions: /* replace entire option list */
ATExecSetRelOptions(rel, (List *) cmd->def, cmd->subtype, lockmode);
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
break;
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
case AT_EnableTrig: /* ENABLE TRIGGER name */
ATExecEnableDisableTrigger(rel, cmd->name,
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
TRIGGER_FIRES_ON_ORIGIN, false, lockmode);
Changes pg_trigger and extend pg_rewrite in order to allow triggers and 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
2007-03-20 00:38:32 +01:00
break;
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
case AT_EnableAlwaysTrig: /* ENABLE ALWAYS TRIGGER name */
ATExecEnableDisableTrigger(rel, cmd->name,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
TRIGGER_FIRES_ALWAYS, false, lockmode);
Changes pg_trigger and extend pg_rewrite in order to allow triggers and 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
2007-03-20 00:38:32 +01:00
break;
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
case AT_EnableReplicaTrig: /* ENABLE REPLICA TRIGGER name */
ATExecEnableDisableTrigger(rel, cmd->name,
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
TRIGGER_FIRES_ON_REPLICA, false, lockmode);
Add ALTER TABLE ENABLE/DISABLE TRIGGER commands. Change pg_dump to use these instead of its previous hack of changing pg_class.reltriggers. Documentation is lacking, will add that later. Patch by Satoshi Nagayasu, review and some extra work by Tom Lane.
2005-08-24 00:40:47 +02:00
break;
case AT_DisableTrig: /* DISABLE TRIGGER name */
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
ATExecEnableDisableTrigger(rel, cmd->name,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
TRIGGER_DISABLED, false, lockmode);
Add ALTER TABLE ENABLE/DISABLE TRIGGER commands. Change pg_dump to use these instead of its previous hack of changing pg_class.reltriggers. Documentation is lacking, will add that later. Patch by Satoshi Nagayasu, review and some extra work by Tom Lane.
2005-08-24 00:40:47 +02:00
break;
case AT_EnableTrigAll: /* ENABLE TRIGGER ALL */
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
ATExecEnableDisableTrigger(rel, NULL,
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
TRIGGER_FIRES_ON_ORIGIN, false, lockmode);
Add ALTER TABLE ENABLE/DISABLE TRIGGER commands. Change pg_dump to use these instead of its previous hack of changing pg_class.reltriggers. Documentation is lacking, will add that later. Patch by Satoshi Nagayasu, review and some extra work by Tom Lane.
2005-08-24 00:40:47 +02:00
break;
case AT_DisableTrigAll: /* DISABLE TRIGGER ALL */
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
ATExecEnableDisableTrigger(rel, NULL,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
TRIGGER_DISABLED, false, lockmode);
Add ALTER TABLE ENABLE/DISABLE TRIGGER commands. Change pg_dump to use these instead of its previous hack of changing pg_class.reltriggers. Documentation is lacking, will add that later. Patch by Satoshi Nagayasu, review and some extra work by Tom Lane.
2005-08-24 00:40:47 +02:00
break;
case AT_EnableTrigUser: /* ENABLE TRIGGER USER */
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
ATExecEnableDisableTrigger(rel, NULL,
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
TRIGGER_FIRES_ON_ORIGIN, true, lockmode);
Add ALTER TABLE ENABLE/DISABLE TRIGGER commands. Change pg_dump to use these instead of its previous hack of changing pg_class.reltriggers. Documentation is lacking, will add that later. Patch by Satoshi Nagayasu, review and some extra work by Tom Lane.
2005-08-24 00:40:47 +02:00
break;
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
case AT_DisableTrigUser: /* DISABLE TRIGGER USER */
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
ATExecEnableDisableTrigger(rel, NULL,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
TRIGGER_DISABLED, true, lockmode);
Changes pg_trigger and extend pg_rewrite in order to allow triggers and 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
2007-03-20 00:38:32 +01:00
break;
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
case AT_EnableRule: /* ENABLE RULE name */
ATExecEnableDisableRule(rel, cmd->name,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
RULE_FIRES_ON_ORIGIN, lockmode);
Changes pg_trigger and extend pg_rewrite in order to allow triggers and 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
2007-03-20 00:38:32 +01:00
break;
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
case AT_EnableAlwaysRule: /* ENABLE ALWAYS RULE name */
ATExecEnableDisableRule(rel, cmd->name,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
RULE_FIRES_ALWAYS, lockmode);
Changes pg_trigger and extend pg_rewrite in order to allow triggers and 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
2007-03-20 00:38:32 +01:00
break;
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
case AT_EnableReplicaRule: /* ENABLE REPLICA RULE name */
ATExecEnableDisableRule(rel, cmd->name,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
RULE_FIRES_ON_REPLICA, lockmode);
Changes pg_trigger and extend pg_rewrite in order to allow triggers and 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
2007-03-20 00:38:32 +01:00
break;
case AT_DisableRule: /* DISABLE RULE name */
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
ATExecEnableDisableRule(rel, cmd->name,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
RULE_DISABLED, lockmode);
Add ALTER TABLE ENABLE/DISABLE TRIGGER commands. Change pg_dump to use these instead of its previous hack of changing pg_class.reltriggers. Documentation is lacking, will add that later. Patch by Satoshi Nagayasu, review and some extra work by Tom Lane.
2005-08-24 00:40:47 +02:00
break;
Changes pg_trigger and extend pg_rewrite in order to allow triggers and 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
2007-03-20 00:38:32 +01:00
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
case AT_AddInherit:
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecAddInherit(rel, (RangeVar *) cmd->def, lockmode);
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
break;
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
case AT_DropInherit:
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecDropInherit(rel, (RangeVar *) cmd->def, lockmode);
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
break;
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
case AT_AddOf:
ATExecAddOf(rel, (TypeName *) cmd->def, lockmode);
break;
case AT_DropOf:
ATExecDropOf(rel, lockmode);
break;
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
case AT_GenericOptions:
ATExecGenericOptions(rel, (List *) cmd->def);
break;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
default: /* oops */
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
elog(ERROR, "unrecognized alter table type: %d",
(int) cmd->subtype);
break;
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
}
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Bump the command counter to ensure the next subcommand in the sequence
* can see the changes so far
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
CommandCounterIncrement();
}
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* ATRewriteTables: ALTER TABLE phase 3
*/
static void
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATRewriteTables(List **wqueue, LOCKMODE lockmode)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *ltab;
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Go through each table that needs to be checked or rewritten */
foreach(ltab, *wqueue)
{
AlteredTableInfo *tab = (AlteredTableInfo *) lfirst(ltab);
Avoid creating a TOAST table if we can prove that the maximum tuple length is < TOAST_TUPLE_THRESHOLD, even with toastable column types present. For example, CREATE TABLE foo (f1 int, f2 varchar(100)) does not require a toast table, even though varchar is a toastable type.
2000-08-25 20:05:54 +02:00
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
/* Foreign tables have no storage. */
if (tab->relkind == RELKIND_FOREIGN_TABLE)
continue;
Teach ALTER TABLE .. SET DATA TYPE to avoid some table rewrites. 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
2011-02-12 14:27:55 +01:00
/*
* If we change column data types or add/remove OIDs, the operation
* has to be propagated to tables that use this table's rowtype as a
* column type. tab->newvals will also be non-NULL in the case where
* we're adding a column with a default. We choose to forbid that
* case as well, since composite types might eventually support
* defaults.
*
* (Eventually we'll probably need to check for composite type
* dependencies even when we're just scanning the table without a
* rewrite, but at the moment a composite type does not enforce any
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
* constraints, so it's not necessary/appropriate to enforce them just
* during ALTER.)
Teach ALTER TABLE .. SET DATA TYPE to avoid some table rewrites. 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
2011-02-12 14:27:55 +01:00
*/
if (tab->newvals != NIL || tab->rewrite)
{
Relation rel;
rel = heap_open(tab->relid, NoLock);
find_composite_type_dependencies(rel->rd_rel->reltype, rel, NULL);
heap_close(rel, NoLock);
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* We only need to rewrite the table if at least one column needs to
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
* be recomputed, or we are adding/removing the OID column.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
Teach ALTER TABLE .. SET DATA TYPE to avoid some table rewrites. 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
2011-02-12 14:27:55 +01:00
if (tab->rewrite)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
/* Build a temporary relation and copy data */
Restructure CLUSTER/newstyle VACUUM FULL/ALTER TABLE support so that swapping of old and new toast tables can be done either at the logical level (by swapping the heaps' reltoastrelid links) or at the physical level (by swapping the relfilenodes of the toast tables and their indexes). This is necessary infrastructure for upcoming changes to support CLUSTER/VAC FULL on shared system catalogs, where we cannot change reltoastrelid. The physical swap saves a few catalog updates too. We unfortunately have to keep the logical-level swap logic because in some cases we will be adding or deleting a toast table, so there's no possibility of a physical swap. However, that only happens as a consequence of schema changes in the table, which we do not need to support for system catalogs, so such cases aren't an obstacle for that. In passing, refactor the cluster support functions a little bit to eliminate unnecessarily-duplicated code; and fix the problem that while CLUSTER had been taught to rename the final toast table at need, ALTER TABLE had not.
2010-02-04 01:09:14 +01:00
Relation OldHeap;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Oid OIDNewHeap;
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
Oid NewTableSpace;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
OldHeap = heap_open(tab->relid, NoLock);
Get rid of cluster.c's apparatus for rebuilding a relation's indexes in favor of using the REINDEX TABLE apparatus, which does the same thing simpler and faster. Also, make TRUNCATE not use cluster.c at all, but just assign a new relfilenode and REINDEX. This partially addresses Hartmut Raschick's complaint from last December that 7.4's TRUNCATE is an order of magnitude slower than prior releases. By getting rid of a lot of unnecessary catalog updates, these changes buy back about a factor of two (on my system). The remaining overhead seems associated with creating and deleting storage files, which we may not be able to do much about without abandoning transaction safety for TRUNCATE.
2004-05-08 02:34:49 +02:00
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* We don't support rewriting of system catalogs; there are too
* many corner cases and too little benefit. In particular this
* is certainly not going to work for mapped catalogs.
Get rid of cluster.c's apparatus for rebuilding a relation's indexes in favor of using the REINDEX TABLE apparatus, which does the same thing simpler and faster. Also, make TRUNCATE not use cluster.c at all, but just assign a new relfilenode and REINDEX. This partially addresses Hartmut Raschick's complaint from last December that 7.4's TRUNCATE is an order of magnitude slower than prior releases. By getting rid of a lot of unnecessary catalog updates, these changes buy back about a factor of two (on my system). The remaining overhead seems associated with creating and deleting storage files, which we may not be able to do much about without abandoning transaction safety for TRUNCATE.
2004-05-08 02:34:49 +02:00
*/
Create a "relation mapping" infrastructure to support changing the relfilenodes of shared or nailed system catalogs. This has two key benefits: * The new CLUSTER-based VACUUM FULL can be applied safely to all catalogs. * We no longer have to use an unsafe reindex-in-place approach for reindexing shared catalogs. CLUSTER on nailed catalogs now works too, although I left it disabled on shared catalogs because the resulting pg_index.indisclustered update would only be visible in one database. Since reindexing shared system catalogs is now fully transactional and crash-safe, the former special cases in REINDEX behavior have been removed; shared catalogs are treated the same as non-shared. This commit does not do anything about the recently-discussed problem of deadlocks between VACUUM FULL/CLUSTER on a system catalog and other concurrent queries; will address that in a separate patch. As a stopgap, parallel_schedule has been tweaked to run vacuum.sql by itself, to avoid such failures during the regression tests.
2010-02-07 21:48:13 +01:00
if (IsSystemRelation(OldHeap))
Get rid of cluster.c's apparatus for rebuilding a relation's indexes in favor of using the REINDEX TABLE apparatus, which does the same thing simpler and faster. Also, make TRUNCATE not use cluster.c at all, but just assign a new relfilenode and REINDEX. This partially addresses Hartmut Raschick's complaint from last December that 7.4's TRUNCATE is an order of magnitude slower than prior releases. By getting rid of a lot of unnecessary catalog updates, these changes buy back about a factor of two (on my system). The remaining overhead seems associated with creating and deleting storage files, which we may not be able to do much about without abandoning transaction safety for TRUNCATE.
2004-05-08 02:34:49 +02:00
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot rewrite system relation \"%s\"",
RelationGetRelationName(OldHeap))));
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Don't allow rewrite on temp tables of other backends ... their
* local buffer manager is not going to cope.
Get rid of cluster.c's apparatus for rebuilding a relation's indexes in favor of using the REINDEX TABLE apparatus, which does the same thing simpler and faster. Also, make TRUNCATE not use cluster.c at all, but just assign a new relfilenode and REINDEX. This partially addresses Hartmut Raschick's complaint from last December that 7.4's TRUNCATE is an order of magnitude slower than prior releases. By getting rid of a lot of unnecessary catalog updates, these changes buy back about a factor of two (on my system). The remaining overhead seems associated with creating and deleting storage files, which we may not be able to do much about without abandoning transaction safety for TRUNCATE.
2004-05-08 02:34:49 +02:00
*/
Modify the relcache to record the temp status of both local and nonlocal temp relations; this is no more expensive than before, now that we have pg_class.relistemp. Insert tests into bufmgr.c to prevent attempting to fetch pages from nonlocal temp relations. This provides a low-level defense against bugs-of-omission allowing temp pages to be loaded into shared buffers, as in the contrib/pgstattuple problem reported by Stuart Bishop. While at it, tweak a bunch of places to use new relcache tests (instead of expensive probes into pg_namespace) to detect local or nonlocal temp tables.
2009-04-01 00:12:48 +02:00
if (RELATION_IS_OTHER_TEMP(OldHeap))
Get rid of cluster.c's apparatus for rebuilding a relation's indexes in favor of using the REINDEX TABLE apparatus, which does the same thing simpler and faster. Also, make TRUNCATE not use cluster.c at all, but just assign a new relfilenode and REINDEX. This partially addresses Hartmut Raschick's complaint from last December that 7.4's TRUNCATE is an order of magnitude slower than prior releases. By getting rid of a lot of unnecessary catalog updates, these changes buy back about a factor of two (on my system). The remaining overhead seems associated with creating and deleting storage files, which we may not be able to do much about without abandoning transaction safety for TRUNCATE.
2004-05-08 02:34:49 +02:00
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("cannot rewrite temporary tables of other sessions")));
Get rid of cluster.c's apparatus for rebuilding a relation's indexes in favor of using the REINDEX TABLE apparatus, which does the same thing simpler and faster. Also, make TRUNCATE not use cluster.c at all, but just assign a new relfilenode and REINDEX. This partially addresses Hartmut Raschick's complaint from last December that 7.4's TRUNCATE is an order of magnitude slower than prior releases. By getting rid of a lot of unnecessary catalog updates, these changes buy back about a factor of two (on my system). The remaining overhead seems associated with creating and deleting storage files, which we may not be able to do much about without abandoning transaction safety for TRUNCATE.
2004-05-08 02:34:49 +02:00
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
/*
* Select destination tablespace (same as original unless user
* requested a change)
*/
if (tab->newTableSpace)
NewTableSpace = tab->newTableSpace;
else
NewTableSpace = OldHeap->rd_rel->reltablespace;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
heap_close(OldHeap, NoLock);
Change SearchSysCache coding conventions so that a reference count is maintained for each cache entry. A cache entry will not be freed until the matching ReleaseSysCache call has been executed. This eliminates worries about cache entries getting dropped while still in use. See my posting to pg-hackers of even date for more info.
2000-11-16 23:30:52 +01:00
Restructure CLUSTER/newstyle VACUUM FULL/ALTER TABLE support so that swapping of old and new toast tables can be done either at the logical level (by swapping the heaps' reltoastrelid links) or at the physical level (by swapping the relfilenodes of the toast tables and their indexes). This is necessary infrastructure for upcoming changes to support CLUSTER/VAC FULL on shared system catalogs, where we cannot change reltoastrelid. The physical swap saves a few catalog updates too. We unfortunately have to keep the logical-level swap logic because in some cases we will be adding or deleting a toast table, so there's no possibility of a physical swap. However, that only happens as a consequence of schema changes in the table, which we do not need to support for system catalogs, so such cases aren't an obstacle for that. In passing, refactor the cluster support functions a little bit to eliminate unnecessarily-duplicated code; and fix the problem that while CLUSTER had been taught to rename the final toast table at need, ALTER TABLE had not.
2010-02-04 01:09:14 +01:00
/* Create transient table that will receive the modified data */
OIDNewHeap = make_new_heap(tab->relid, NewTableSpace);
Bugfix in ALTER TABLE CREATE TOAST TABLE Automatically create toast table at CREATE TABLE if new table has toastable attributes. Jan
2000-07-05 14:45:31 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* Copy the heap data into the new table with the desired
* modifications, and test the current data within the table
* against new constraints generated by ALTER TABLE commands.
*/
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATRewriteTable(tab, OIDNewHeap, lockmode);
TOAST WARNING: This is actually broken - we have self-deadlocks due to concurrent changes in buffer management. Vadim and me are working on it. Jan
2000-07-04 01:10:14 +02:00
Have CLUSTER advance the table's relfrozenxid. The new frozen point is the 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.
2007-05-19 01:19:42 +02:00
/*
Create a "relation mapping" infrastructure to support changing the relfilenodes of shared or nailed system catalogs. This has two key benefits: * The new CLUSTER-based VACUUM FULL can be applied safely to all catalogs. * We no longer have to use an unsafe reindex-in-place approach for reindexing shared catalogs. CLUSTER on nailed catalogs now works too, although I left it disabled on shared catalogs because the resulting pg_index.indisclustered update would only be visible in one database. Since reindexing shared system catalogs is now fully transactional and crash-safe, the former special cases in REINDEX behavior have been removed; shared catalogs are treated the same as non-shared. This commit does not do anything about the recently-discussed problem of deadlocks between VACUUM FULL/CLUSTER on a system catalog and other concurrent queries; will address that in a separate patch. As a stopgap, parallel_schedule has been tweaked to run vacuum.sql by itself, to avoid such failures during the regression tests.
2010-02-07 21:48:13 +01:00
* Swap the physical files of the old and new heaps, then rebuild
Make ALTER TABLE revalidate uniqueness and exclusion constraints. Failure to do so can lead to constraint violations. This was broken by commit 1ddc2703a936d03953657f43345460b9242bbed1 on 2010-02-07, so back-patch to 9.0. Noah Misch. Regression test by me.
2011-01-21 04:44:10 +01:00
* indexes and discard the old heap. We can use RecentXmin for
Create a "relation mapping" infrastructure to support changing the relfilenodes of shared or nailed system catalogs. This has two key benefits: * The new CLUSTER-based VACUUM FULL can be applied safely to all catalogs. * We no longer have to use an unsafe reindex-in-place approach for reindexing shared catalogs. CLUSTER on nailed catalogs now works too, although I left it disabled on shared catalogs because the resulting pg_index.indisclustered update would only be visible in one database. Since reindexing shared system catalogs is now fully transactional and crash-safe, the former special cases in REINDEX behavior have been removed; shared catalogs are treated the same as non-shared. This commit does not do anything about the recently-discussed problem of deadlocks between VACUUM FULL/CLUSTER on a system catalog and other concurrent queries; will address that in a separate patch. As a stopgap, parallel_schedule has been tweaked to run vacuum.sql by itself, to avoid such failures during the regression tests.
2010-02-07 21:48:13 +01:00
* the table's new relfrozenxid because we rewrote all the tuples
* in ATRewriteTable, so no older Xid remains in the table. Also,
* we never try to swap toast tables by content, since we have no
* interest in letting this code work on system catalogs.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
Make ALTER TABLE revalidate uniqueness and exclusion constraints. Failure to do so can lead to constraint violations. This was broken by commit 1ddc2703a936d03953657f43345460b9242bbed1 on 2010-02-07, so back-patch to 9.0. Noah Misch. Regression test by me.
2011-01-21 04:44:10 +01:00
finish_heap_swap(tab->relid, OIDNewHeap,
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
false, false, true,
!OidIsValid(tab->newTableSpace),
RecentXmin,
Improve concurrency of foreign key locking This patch introduces two additional lock modes for tuples: "SELECT FOR KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each other, in contrast with already existing "SELECT FOR SHARE" and "SELECT FOR UPDATE". UPDATE commands that do not modify the values stored in the columns that are part of the key of the tuple now grab a SELECT FOR NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently with tuple locks of the FOR KEY SHARE variety. Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this means the concurrency improvement applies to them, which is the whole point of this patch. The added tuple lock semantics require some rejiggering of the multixact module, so that the locking level that each transaction is holding can be stored alongside its Xid. Also, multixacts now need to persist across server restarts and crashes, because they can now represent not only tuple locks, but also tuple updates. This means we need more careful tracking of lifetime of pg_multixact SLRU files; since they now persist longer, we require more infrastructure to figure out when they can be removed. pg_upgrade also needs to be careful to copy pg_multixact files over from the old server to the new, or at least part of multixact.c state, depending on the versions of the old and new servers. Tuple time qualification rules (HeapTupleSatisfies routines) need to be careful not to consider tuples with the "is multi" infomask bit set as being only locked; they might need to look up MultiXact values (i.e. possibly do pg_multixact I/O) to find out the Xid that updated a tuple, whereas they previously were assured to only use information readily available from the tuple header. This is considered acceptable, because the extra I/O would involve cases that would previously cause some commands to block waiting for concurrent transactions to finish. Another important change is the fact that locking tuples that have previously been updated causes the future versions to be marked as locked, too; this is essential for correctness of foreign key checks. This causes additional WAL-logging, also (there was previously a single WAL record for a locked tuple; now there are as many as updated copies of the tuple there exist.) With all this in place, contention related to tuples being checked by foreign key rules should be much reduced. As a bonus, the old behavior that a subtransaction grabbing a stronger tuple lock than the parent (sub)transaction held on a given tuple and later aborting caused the weaker lock to be lost, has been fixed. Many new spec files were added for isolation tester framework, to ensure overall behavior is sane. There's probably room for several more tests. There were several reviewers of this patch; in particular, Noah Misch and Andres Freund spent considerable time in it. Original idea for the patch came from Simon Riggs, after a problem report by Joel Jacobson. Most code is from me, with contributions from Marti Raudsepp, Alexander Shulgin, Noah Misch and Andres Freund. This patch was discussed in several pgsql-hackers threads; the most important start at the following message-ids: AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com 1290721684-sup-3951@alvh.no-ip.org 1294953201-sup-2099@alvh.no-ip.org 1320343602-sup-2290@alvh.no-ip.org 1339690386-sup-8927@alvh.no-ip.org 4FE5FF020200002500048A3D@gw.wicourts.gov 4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
ReadNextMultiXactId());
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
else
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Test the current data within the table against new constraints
* generated by ALTER TABLE commands, but don't rebuild data.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
Fix ALTER TABLE to check pre-existing NOT NULL constraints when rewriting 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.
2006-07-11 00:10:39 +02:00
if (tab->constraints != NIL || tab->new_notnull)
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATRewriteTable(tab, InvalidOid, lockmode);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* If we had SET TABLESPACE but no reason to reconstruct tuples,
* just do a block-by-block copy.
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
*/
if (tab->newTableSpace)
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecSetTableSpace(tab->relid, tab->newTableSpace, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
}
Make toast-table creation and deletion work somewhat reliably. Don't go through pg_exec_query_dest(), but directly to the execution routines. Also, extend parameter lists so that there's no need to change the global setting of allowSystemTableMods, a hack that was certain to cause trouble in the event of any error.
2000-07-04 08:11:54 +02:00
Make OIDs optional, per discussions in pghackers. WITH OIDS is still the default, but OIDS are removed from many system catalogs that don't need them. Some interesting side effects: TOAST pointers are 20 bytes not 32 now; pg_description has a three-column key instead of one. Bugs fixed in passing: BINARY cursors work again; pg_class.relhaspkey has some usefulness; pg_dump dumps comments on indexes, rules, and triggers in a valid order. initdb forced.
2001-08-10 20:57:42 +02:00
/*
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
* Foreign key constraints are checked in a final pass, since (a) it's
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* generally best to examine each one separately, and (b) it's at least
* theoretically possible that we have changed both relations of the
* foreign key, and we'd better have finished both rewrites before we try
* to read the tables.
Make OIDs optional, per discussions in pghackers. WITH OIDS is still the default, but OIDS are removed from many system catalogs that don't need them. Some interesting side effects: TOAST pointers are 20 bytes not 32 now; pg_description has a three-column key instead of one. Bugs fixed in passing: BINARY cursors work again; pg_class.relhaspkey has some usefulness; pg_dump dumps comments on indexes, rules, and triggers in a valid order. initdb forced.
2001-08-10 20:57:42 +02:00
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
foreach(ltab, *wqueue)
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
AlteredTableInfo *tab = (AlteredTableInfo *) lfirst(ltab);
Relation rel = NULL;
ListCell *lcon;
Cleanup of code for creating index entries. Functional indexes with pass-by-ref data types --- eg, an index on lower(textfield) --- no longer leak memory during index creation or update. Clean up a lot of redundant code ... did you know that copy, vacuum, truncate, reindex, extend index, and bootstrap each basically duplicated the main executor's logic for extracting information about an index and preparing index entries? Functional indexes should be a little faster now too, due to removal of repeated function lookups. CREATE INDEX 'opt_type' clause is deimplemented by these changes, but I haven't removed it from the parser yet (need to merge with Thomas' latest change set first).
2000-07-15 00:18:02 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
foreach(lcon, tab->constraints)
{
NewConstraint *con = lfirst(lcon);
Code review for HeapTupleHeader changes. Add version number to page headers (overlaying low byte of page size) and add HEAP_HASOID bit to t_infomask, per earlier discussion. Simplify scheme for overlaying fields in tuple header (no need for cmax to live in more than one place). Don't try to clear infomask status bits in tqual.c --- not safe to do it there. Don't try to force output table of a SELECT INTO to have OIDs, either. Get rid of unnecessarily complex three-state scheme for TupleDesc.tdhasoids, which has already caused one recent failure. Improve documentation.
2002-09-02 03:05:06 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (con->contype == CONSTR_FOREIGN)
{
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
Constraint *fkconstraint = (Constraint *) con->qual;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Relation refrel;
Cleanup of code for creating index entries. Functional indexes with pass-by-ref data types --- eg, an index on lower(textfield) --- no longer leak memory during index creation or update. Clean up a lot of redundant code ... did you know that copy, vacuum, truncate, reindex, extend index, and bootstrap each basically duplicated the main executor's logic for extracting information about an index and preparing index entries? Functional indexes should be a little faster now too, due to removal of repeated function lookups. CREATE INDEX 'opt_type' clause is deimplemented by these changes, but I haven't removed it from the parser yet (need to merge with Thomas' latest change set first).
2000-07-15 00:18:02 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (rel == NULL)
Finish disabling reduced-lock-levels-for-DDL feature. Previous patch only covered the ALTER TABLE changes, not changes in other commands; and it neglected to revert the documentation changes.
2011-07-07 19:14:46 +02:00
{
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Long since locked, no need for another */
rel = heap_open(tab->relid, NoLock);
Finish disabling reduced-lock-levels-for-DDL feature. Previous patch only covered the ALTER TABLE changes, not changes in other commands; and it neglected to revert the documentation changes.
2011-07-07 19:14:46 +02:00
}
Make toast-table creation and deletion work somewhat reliably. Don't go through pg_exec_query_dest(), but directly to the execution routines. Also, extend parameter lists so that there's no need to change the global setting of allowSystemTableMods, a hack that was certain to cause trouble in the event of any error.
2000-07-04 08:11:54 +02:00
Finish disabling reduced-lock-levels-for-DDL feature. Previous patch only covered the ALTER TABLE changes, not changes in other commands; and it neglected to revert the documentation changes.
2011-07-07 19:14:46 +02:00
refrel = heap_open(con->refrelid, RowShareLock);
TOAST WARNING: This is actually broken - we have self-deadlocks due to concurrent changes in buffer management. Vadim and me are working on it. Jan
2000-07-04 01:10:14 +02:00
Extend ALTER TABLE to allow Foreign Keys to be added without initial validation. 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
2011-02-08 13:23:20 +01:00
validateForeignKeyConstraint(fkconstraint->conname, rel, refrel,
Add system catalog columns pg_constraint.conindid and pg_trigger.tgconstrindid. conindid is the index supporting a constraint. We can use this not only for unique/primary-key constraints, but also foreign-key constraints, which depend on the unique index that constrains the referenced columns. tgconstrindid is just copied from the constraint's conindid field, or is zero for triggers not associated with constraints. This is mainly intended as infrastructure for upcoming patches, but it has some virtue in itself, since it exposes a relationship that you formerly had to grovel in pg_depend to determine. I simplified one information_schema view accordingly. (There is a pg_dump query that could also use conindid, but I left it alone because it wasn't clear it'd get any faster.)
2009-07-28 04:56:31 +02:00
con->refindid,
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
con->conid);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
Extend ALTER TABLE to allow Foreign Keys to be added without initial validation. 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
2011-02-08 13:23:20 +01:00
/*
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
* No need to mark the constraint row as validated, we did
* that when we inserted the row earlier.
Extend ALTER TABLE to allow Foreign Keys to be added without initial validation. 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
2011-02-08 13:23:20 +01:00
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
heap_close(refrel, NoLock);
}
}
TOAST WARNING: This is actually broken - we have self-deadlocks due to concurrent changes in buffer management. Vadim and me are working on it. Jan
2000-07-04 01:10:14 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (rel)
heap_close(rel, NoLock);
}
}
Add more dependency insertions --- this completes the basic pg_depend functionality. Of note: dropping a table that has a SERIAL column defined now drops the associated sequence automatically.
2002-07-17 00:12:20 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* ATRewriteTable: scan or rewrite one table
*
* OIDNewHeap is InvalidOid if we don't need to rewrite
*/
static void
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATRewriteTable(AlteredTableInfo *tab, Oid OIDNewHeap, LOCKMODE lockmode)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
Relation oldrel;
Relation newrel;
TupleDesc oldTupDesc;
TupleDesc newTupDesc;
bool needscan = false;
Fix ALTER TABLE to check pre-existing NOT NULL constraints when rewriting 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.
2006-07-11 00:10:39 +02:00
List *notnull_attrs;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
int i;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *l;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
EState *estate;
Allow rewriting ALTER TABLE to skip WAL logging. Itagaki Takahiro, with small changes by me and Simon.
2009-11-04 13:24:23 +01:00
CommandId mycid;
BulkInsertState bistate;
int hi_options;
TOAST WARNING: This is actually broken - we have self-deadlocks due to concurrent changes in buffer management. Vadim and me are working on it. Jan
2000-07-04 01:10:14 +02:00
Changed TOAST relations to have relkind RELKIND_TOASTVALUE. Special handling of TOAST relations during VACUUM. TOAST relations are vacuumed while the lock on the master table is still active. The ANALYZE flag doesn't propagate to their vacuuming because the toaster access routines allways use index access ignoring stats, so why compute them at all. Protection of TOAST relations against normal INSERT/UPDATE/DELETE while offering SELECT for debugging purposes. Jan
2000-07-05 18:17:43 +02:00
/*
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* Open the relation(s). We have surely already locked the existing
* table.
Changed TOAST relations to have relkind RELKIND_TOASTVALUE. Special handling of TOAST relations during VACUUM. TOAST relations are vacuumed while the lock on the master table is still active. The ANALYZE flag doesn't propagate to their vacuuming because the toaster access routines allways use index access ignoring stats, so why compute them at all. Protection of TOAST relations against normal INSERT/UPDATE/DELETE while offering SELECT for debugging purposes. Jan
2000-07-05 18:17:43 +02:00
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
oldrel = heap_open(tab->relid, NoLock);
oldTupDesc = tab->oldDesc;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
newTupDesc = RelationGetDescr(oldrel); /* includes all mods */
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (OidIsValid(OIDNewHeap))
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
newrel = heap_open(OIDNewHeap, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
else
newrel = NULL;
Automatically create toast tables on ALTER TABLE ... ADD COLUMN and SELECT ... INTO ... too. Jan
2000-07-05 15:22:25 +02:00
Allow rewriting ALTER TABLE to skip WAL logging. Itagaki Takahiro, with small changes by me and Simon.
2009-11-04 13:24:23 +01:00
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* Prepare a BulkInsertState and options for heap_insert. Because we're
* building a new heap, we can skip WAL-logging and fsync it to disk at
* the end instead (unless WAL-logging is required for archiving or
* streaming replication). The FSM is empty too, so don't bother using it.
Allow rewriting ALTER TABLE to skip WAL logging. Itagaki Takahiro, with small changes by me and Simon.
2009-11-04 13:24:23 +01:00
*/
if (newrel)
{
mycid = GetCurrentCommandId(true);
bistate = GetBulkInsertState();
hi_options = HEAP_INSERT_SKIP_FSM;
Change a few remaining calls of XLogArchivingActive() to use XLogIsNeeded() instead, to determine if an otherwise non-logged operation needs to be logged in WAL for standby servers. Fujii Masao
2010-01-28 08:31:42 +01:00
if (!XLogIsNeeded())
Allow rewriting ALTER TABLE to skip WAL logging. Itagaki Takahiro, with small changes by me and Simon.
2009-11-04 13:24:23 +01:00
hi_options |= HEAP_INSERT_SKIP_WAL;
}
else
{
/* keep compiler quiet about using these uninitialized */
mycid = 0;
bistate = NULL;
hi_options = 0;
}
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* Generate the constraint and default execution states
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*/
TOAST WARNING: This is actually broken - we have self-deadlocks due to concurrent changes in buffer management. Vadim and me are working on it. Jan
2000-07-04 01:10:14 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
estate = CreateExecutorState();
Avoid creating a TOAST table if we can prove that the maximum tuple length is < TOAST_TUPLE_THRESHOLD, even with toastable column types present. For example, CREATE TABLE foo (f1 int, f2 varchar(100)) does not require a toast table, even though varchar is a toastable type.
2000-08-25 20:05:54 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Build the needed expression execution states */
foreach(l, tab->constraints)
{
NewConstraint *con = lfirst(l);
Avoid creating a TOAST table if we can prove that the maximum tuple length is < TOAST_TUPLE_THRESHOLD, even with toastable column types present. For example, CREATE TABLE foo (f1 int, f2 varchar(100)) does not require a toast table, even though varchar is a toastable type.
2000-08-25 20:05:54 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
switch (con->contype)
{
case CONSTR_CHECK:
needscan = true;
con->qualstate = (List *)
ExecPrepareExpr((Expr *) con->qual, estate);
break;
case CONSTR_FOREIGN:
/* Nothing to do here */
break;
default:
elog(ERROR, "unrecognized constraint type: %d",
(int) con->contype);
}
}
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
foreach(l, tab->newvals)
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
NewColumnValue *ex = lfirst(l);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
Add notion of a "transform function" that can simplify function calls. 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
2011-06-22 04:15:24 +02:00
/* expr already planned */
ex->exprstate = ExecInitExpr((Expr *) ex->expr, NULL);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
Fix ALTER TABLE to check pre-existing NOT NULL constraints when rewriting 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.
2006-07-11 00:10:39 +02:00
notnull_attrs = NIL;
if (newrel || tab->new_notnull)
{
/*
* If we are rebuilding the tuples OR if we added any new NOT NULL
* constraints, check all not-null constraints. This is a bit of
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* overkill but it minimizes risk of bugs, and heap_attisnull is a
* pretty cheap test anyway.
Fix ALTER TABLE to check pre-existing NOT NULL constraints when rewriting 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.
2006-07-11 00:10:39 +02:00
*/
for (i = 0; i < newTupDesc->natts; i++)
{
if (newTupDesc->attrs[i]->attnotnull &&
!newTupDesc->attrs[i]->attisdropped)
notnull_attrs = lappend_int(notnull_attrs, i);
}
if (notnull_attrs)
needscan = true;
}
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
if (newrel || needscan)
Avoid creating a TOAST table if we can prove that the maximum tuple length is < TOAST_TUPLE_THRESHOLD, even with toastable column types present. For example, CREATE TABLE foo (f1 int, f2 varchar(100)) does not require a toast table, even though varchar is a toastable type.
2000-08-25 20:05:54 +02:00
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
ExprContext *econtext;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Datum *values;
Revise TupleTableSlot code to avoid unnecessary construction and disassembly of tuples when passing data up through multiple plan nodes. A slot can now hold either a normal "physical" HeapTuple, or a "virtual" tuple consisting of Datum/isnull arrays. Upper plan levels can usually just copy the Datum arrays, avoiding heap_formtuple() and possible subsequent nocachegetattr() calls to extract the data again. This work extends Atsushi Ogawa's earlier patch, which provided the key idea of adding Datum arrays to TupleTableSlots. (I believe however that something like this was foreseen way back in Berkeley days --- see the old comment on ExecProject.) A test case involving many levels of join of fairly wide tables (about 80 columns altogether) showed about 3x overall speedup, though simple queries will probably not be helped very much. I have also duplicated some code in heaptuple.c in order to provide versions of heap_formtuple and friends that use "bool" arrays to indicate null attributes, instead of the old convention of "char" arrays containing either 'n' or ' '. This provides a better match to the convention used by ExecEvalExpr. While I have not made a concerted effort to get rid of uses of the old routines, I think they should be deprecated and eventually removed.
2005-03-16 22:38:10 +01:00
bool *isnull;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
TupleTableSlot *oldslot;
TupleTableSlot *newslot;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
HeapScanDesc scan;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
HeapTuple tuple;
ALTER TABLE ADD COLUMN exhibits a significant memory leak when adding a column with a default expression. In that situation, we need to rewrite the heap relation. To evaluate the new default expression, we use ExecEvalExpr(); however, this can allocate memory in the current memory context, and ATRewriteTable() does not switch out of the active portal's heap memory context. The end result is a rather large memory leak (on the order of gigabytes for a reasonably sized table). This patch changes ATRewriteTable() to switch to the per-tuple memory context before beginning the per-tuple loop. It also removes an explicit heap_freetuple() in the loop, since that is no longer needed. In an unrelated change, I noticed the code was scanning through the attributes of the new tuple descriptor for each tuple of the old table. I changed this to use precomputation, which should slightly speed up the loop. Thanks to steve@deefs.net for reporting the leak.
2005-02-10 00:17:26 +01:00
MemoryContext oldCxt;
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
List *dropped_attrs = NIL;
ListCell *lc;
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
Teach ALTER TABLE .. SET DATA TYPE to avoid some table rewrites. 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
2011-02-12 14:27:55 +01:00
if (newrel)
ereport(DEBUG1,
(errmsg("rewriting table \"%s\"",
RelationGetRelationName(oldrel))));
else
ereport(DEBUG1,
(errmsg("verifying table \"%s\"",
RelationGetRelationName(oldrel))));
Make DDL operations play nicely with Serializable Snapshot Isolation. 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.
2011-06-08 12:47:21 +02:00
if (newrel)
{
/*
* All predicate locks on the tuples or pages are about to be made
* invalid, because we move tuples around. Promote them to
* relation locks.
*/
TransferPredicateLocksToHeapRelation(oldrel);
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
econtext = GetPerTupleExprContext(estate);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Make tuple slots for old and new tuples. Note that even when the
* tuples are the same, the tupDescs might not be (consider ADD COLUMN
* without a default).
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*/
Revise TupleTableSlot code to avoid unnecessary construction and disassembly of tuples when passing data up through multiple plan nodes. A slot can now hold either a normal "physical" HeapTuple, or a "virtual" tuple consisting of Datum/isnull arrays. Upper plan levels can usually just copy the Datum arrays, avoiding heap_formtuple() and possible subsequent nocachegetattr() calls to extract the data again. This work extends Atsushi Ogawa's earlier patch, which provided the key idea of adding Datum arrays to TupleTableSlots. (I believe however that something like this was foreseen way back in Berkeley days --- see the old comment on ExecProject.) A test case involving many levels of join of fairly wide tables (about 80 columns altogether) showed about 3x overall speedup, though simple queries will probably not be helped very much. I have also duplicated some code in heaptuple.c in order to provide versions of heap_formtuple and friends that use "bool" arrays to indicate null attributes, instead of the old convention of "char" arrays containing either 'n' or ' '. This provides a better match to the convention used by ExecEvalExpr. While I have not made a concerted effort to get rid of uses of the old routines, I think they should be deprecated and eventually removed.
2005-03-16 22:38:10 +01:00
oldslot = MakeSingleTupleTableSlot(oldTupDesc);
newslot = MakeSingleTupleTableSlot(newTupDesc);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Revise TupleTableSlot code to avoid unnecessary construction and disassembly of tuples when passing data up through multiple plan nodes. A slot can now hold either a normal "physical" HeapTuple, or a "virtual" tuple consisting of Datum/isnull arrays. Upper plan levels can usually just copy the Datum arrays, avoiding heap_formtuple() and possible subsequent nocachegetattr() calls to extract the data again. This work extends Atsushi Ogawa's earlier patch, which provided the key idea of adding Datum arrays to TupleTableSlots. (I believe however that something like this was foreseen way back in Berkeley days --- see the old comment on ExecProject.) A test case involving many levels of join of fairly wide tables (about 80 columns altogether) showed about 3x overall speedup, though simple queries will probably not be helped very much. I have also duplicated some code in heaptuple.c in order to provide versions of heap_formtuple and friends that use "bool" arrays to indicate null attributes, instead of the old convention of "char" arrays containing either 'n' or ' '. This provides a better match to the convention used by ExecEvalExpr. While I have not made a concerted effort to get rid of uses of the old routines, I think they should be deprecated and eventually removed.
2005-03-16 22:38:10 +01:00
/* Preallocate values/isnull arrays */
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
i = Max(newTupDesc->natts, oldTupDesc->natts);
Resurrect heap_deformtuple(), this time implemented as a singly nested loop over the fields instead of a loop around heap_getattr. This is considerably faster (O(N) instead of O(N^2)) when there are nulls or varlena fields, since those prevent use of attcacheoff. Replace loops over heap_getattr with heap_deformtuple in situations where all or most of the fields have to be fetched, such as printtup and tuptoaster. Profiling done more than a year ago shows that this should be a nice win for situations involving many-column tables.
2004-06-04 22:35:21 +02:00
values = (Datum *) palloc(i * sizeof(Datum));
Revise TupleTableSlot code to avoid unnecessary construction and disassembly of tuples when passing data up through multiple plan nodes. A slot can now hold either a normal "physical" HeapTuple, or a "virtual" tuple consisting of Datum/isnull arrays. Upper plan levels can usually just copy the Datum arrays, avoiding heap_formtuple() and possible subsequent nocachegetattr() calls to extract the data again. This work extends Atsushi Ogawa's earlier patch, which provided the key idea of adding Datum arrays to TupleTableSlots. (I believe however that something like this was foreseen way back in Berkeley days --- see the old comment on ExecProject.) A test case involving many levels of join of fairly wide tables (about 80 columns altogether) showed about 3x overall speedup, though simple queries will probably not be helped very much. I have also duplicated some code in heaptuple.c in order to provide versions of heap_formtuple and friends that use "bool" arrays to indicate null attributes, instead of the old convention of "char" arrays containing either 'n' or ' '. This provides a better match to the convention used by ExecEvalExpr. While I have not made a concerted effort to get rid of uses of the old routines, I think they should be deprecated and eventually removed.
2005-03-16 22:38:10 +01:00
isnull = (bool *) palloc(i * sizeof(bool));
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
memset(values, 0, i * sizeof(Datum));
Revise TupleTableSlot code to avoid unnecessary construction and disassembly of tuples when passing data up through multiple plan nodes. A slot can now hold either a normal "physical" HeapTuple, or a "virtual" tuple consisting of Datum/isnull arrays. Upper plan levels can usually just copy the Datum arrays, avoiding heap_formtuple() and possible subsequent nocachegetattr() calls to extract the data again. This work extends Atsushi Ogawa's earlier patch, which provided the key idea of adding Datum arrays to TupleTableSlots. (I believe however that something like this was foreseen way back in Berkeley days --- see the old comment on ExecProject.) A test case involving many levels of join of fairly wide tables (about 80 columns altogether) showed about 3x overall speedup, though simple queries will probably not be helped very much. I have also duplicated some code in heaptuple.c in order to provide versions of heap_formtuple and friends that use "bool" arrays to indicate null attributes, instead of the old convention of "char" arrays containing either 'n' or ' '. This provides a better match to the convention used by ExecEvalExpr. While I have not made a concerted effort to get rid of uses of the old routines, I think they should be deprecated and eventually removed.
2005-03-16 22:38:10 +01:00
memset(isnull, true, i * sizeof(bool));
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
ALTER TABLE ADD COLUMN exhibits a significant memory leak when adding a column with a default expression. In that situation, we need to rewrite the heap relation. To evaluate the new default expression, we use ExecEvalExpr(); however, this can allocate memory in the current memory context, and ATRewriteTable() does not switch out of the active portal's heap memory context. The end result is a rather large memory leak (on the order of gigabytes for a reasonably sized table). This patch changes ATRewriteTable() to switch to the per-tuple memory context before beginning the per-tuple loop. It also removes an explicit heap_freetuple() in the loop, since that is no longer needed. In an unrelated change, I noticed the code was scanning through the attributes of the new tuple descriptor for each tuple of the old table. I changed this to use precomputation, which should slightly speed up the loop. Thanks to steve@deefs.net for reporting the leak.
2005-02-10 00:17:26 +01:00
/*
* Any attributes that are dropped according to the new tuple
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* descriptor can be set to NULL. We precompute the list of dropped
* attributes to avoid needing to do so in the per-tuple loop.
ALTER TABLE ADD COLUMN exhibits a significant memory leak when adding a column with a default expression. In that situation, we need to rewrite the heap relation. To evaluate the new default expression, we use ExecEvalExpr(); however, this can allocate memory in the current memory context, and ATRewriteTable() does not switch out of the active portal's heap memory context. The end result is a rather large memory leak (on the order of gigabytes for a reasonably sized table). This patch changes ATRewriteTable() to switch to the per-tuple memory context before beginning the per-tuple loop. It also removes an explicit heap_freetuple() in the loop, since that is no longer needed. In an unrelated change, I noticed the code was scanning through the attributes of the new tuple descriptor for each tuple of the old table. I changed this to use precomputation, which should slightly speed up the loop. Thanks to steve@deefs.net for reporting the leak.
2005-02-10 00:17:26 +01:00
*/
for (i = 0; i < newTupDesc->natts; i++)
{
if (newTupDesc->attrs[i]->attisdropped)
dropped_attrs = lappend_int(dropped_attrs, i);
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* Scan through the rows, generating a new row if needed and then
* checking all the constraints.
*/
scan = heap_beginscan(oldrel, SnapshotNow, 0, NULL);
ALTER TABLE ADD COLUMN exhibits a significant memory leak when adding a column with a default expression. In that situation, we need to rewrite the heap relation. To evaluate the new default expression, we use ExecEvalExpr(); however, this can allocate memory in the current memory context, and ATRewriteTable() does not switch out of the active portal's heap memory context. The end result is a rather large memory leak (on the order of gigabytes for a reasonably sized table). This patch changes ATRewriteTable() to switch to the per-tuple memory context before beginning the per-tuple loop. It also removes an explicit heap_freetuple() in the loop, since that is no longer needed. In an unrelated change, I noticed the code was scanning through the attributes of the new tuple descriptor for each tuple of the old table. I changed this to use precomputation, which should slightly speed up the loop. Thanks to steve@deefs.net for reporting the leak.
2005-02-10 00:17:26 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Switch to per-tuple memory context and reset it for each tuple
* produced, so we don't leak memory.
ALTER TABLE ADD COLUMN exhibits a significant memory leak when adding a column with a default expression. In that situation, we need to rewrite the heap relation. To evaluate the new default expression, we use ExecEvalExpr(); however, this can allocate memory in the current memory context, and ATRewriteTable() does not switch out of the active portal's heap memory context. The end result is a rather large memory leak (on the order of gigabytes for a reasonably sized table). This patch changes ATRewriteTable() to switch to the per-tuple memory context before beginning the per-tuple loop. It also removes an explicit heap_freetuple() in the loop, since that is no longer needed. In an unrelated change, I noticed the code was scanning through the attributes of the new tuple descriptor for each tuple of the old table. I changed this to use precomputation, which should slightly speed up the loop. Thanks to steve@deefs.net for reporting the leak.
2005-02-10 00:17:26 +01:00
*/
oldCxt = MemoryContextSwitchTo(GetPerTupleMemoryContext(estate));
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
Avoid creating a TOAST table if we can prove that the maximum tuple length is < TOAST_TUPLE_THRESHOLD, even with toastable column types present. For example, CREATE TABLE foo (f1 int, f2 varchar(100)) does not require a toast table, even though varchar is a toastable type.
2000-08-25 20:05:54 +02:00
{
Teach ALTER TABLE .. SET DATA TYPE to avoid some table rewrites. 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
2011-02-12 14:27:55 +01:00
if (tab->rewrite)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
Oid tupOid = InvalidOid;
Preserve tuple OIDs during ATRewriteTable. Per gripe from Duncan Crombie.
2005-10-03 04:45:12 +02:00
ALTER TABLE ADD COLUMN exhibits a significant memory leak when adding a column with a default expression. In that situation, we need to rewrite the heap relation. To evaluate the new default expression, we use ExecEvalExpr(); however, this can allocate memory in the current memory context, and ATRewriteTable() does not switch out of the active portal's heap memory context. The end result is a rather large memory leak (on the order of gigabytes for a reasonably sized table). This patch changes ATRewriteTable() to switch to the per-tuple memory context before beginning the per-tuple loop. It also removes an explicit heap_freetuple() in the loop, since that is no longer needed. In an unrelated change, I noticed the code was scanning through the attributes of the new tuple descriptor for each tuple of the old table. I changed this to use precomputation, which should slightly speed up the loop. Thanks to steve@deefs.net for reporting the leak.
2005-02-10 00:17:26 +01:00
/* Extract data from old tuple */
Revise TupleTableSlot code to avoid unnecessary construction and disassembly of tuples when passing data up through multiple plan nodes. A slot can now hold either a normal "physical" HeapTuple, or a "virtual" tuple consisting of Datum/isnull arrays. Upper plan levels can usually just copy the Datum arrays, avoiding heap_formtuple() and possible subsequent nocachegetattr() calls to extract the data again. This work extends Atsushi Ogawa's earlier patch, which provided the key idea of adding Datum arrays to TupleTableSlots. (I believe however that something like this was foreseen way back in Berkeley days --- see the old comment on ExecProject.) A test case involving many levels of join of fairly wide tables (about 80 columns altogether) showed about 3x overall speedup, though simple queries will probably not be helped very much. I have also duplicated some code in heaptuple.c in order to provide versions of heap_formtuple and friends that use "bool" arrays to indicate null attributes, instead of the old convention of "char" arrays containing either 'n' or ' '. This provides a better match to the convention used by ExecEvalExpr. While I have not made a concerted effort to get rid of uses of the old routines, I think they should be deprecated and eventually removed.
2005-03-16 22:38:10 +01:00
heap_deform_tuple(tuple, oldTupDesc, values, isnull);
Preserve tuple OIDs during ATRewriteTable. Per gripe from Duncan Crombie.
2005-10-03 04:45:12 +02:00
if (oldTupDesc->tdhasoid)
tupOid = HeapTupleGetOid(tuple);
Avoid creating a TOAST table if we can prove that the maximum tuple length is < TOAST_TUPLE_THRESHOLD, even with toastable column types present. For example, CREATE TABLE foo (f1 int, f2 varchar(100)) does not require a toast table, even though varchar is a toastable type.
2000-08-25 20:05:54 +02:00
ALTER TABLE ADD COLUMN exhibits a significant memory leak when adding a column with a default expression. In that situation, we need to rewrite the heap relation. To evaluate the new default expression, we use ExecEvalExpr(); however, this can allocate memory in the current memory context, and ATRewriteTable() does not switch out of the active portal's heap memory context. The end result is a rather large memory leak (on the order of gigabytes for a reasonably sized table). This patch changes ATRewriteTable() to switch to the per-tuple memory context before beginning the per-tuple loop. It also removes an explicit heap_freetuple() in the loop, since that is no longer needed. In an unrelated change, I noticed the code was scanning through the attributes of the new tuple descriptor for each tuple of the old table. I changed this to use precomputation, which should slightly speed up the loop. Thanks to steve@deefs.net for reporting the leak.
2005-02-10 00:17:26 +01:00
/* Set dropped attributes to null in new tuple */
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
foreach(lc, dropped_attrs)
Revise TupleTableSlot code to avoid unnecessary construction and disassembly of tuples when passing data up through multiple plan nodes. A slot can now hold either a normal "physical" HeapTuple, or a "virtual" tuple consisting of Datum/isnull arrays. Upper plan levels can usually just copy the Datum arrays, avoiding heap_formtuple() and possible subsequent nocachegetattr() calls to extract the data again. This work extends Atsushi Ogawa's earlier patch, which provided the key idea of adding Datum arrays to TupleTableSlots. (I believe however that something like this was foreseen way back in Berkeley days --- see the old comment on ExecProject.) A test case involving many levels of join of fairly wide tables (about 80 columns altogether) showed about 3x overall speedup, though simple queries will probably not be helped very much. I have also duplicated some code in heaptuple.c in order to provide versions of heap_formtuple and friends that use "bool" arrays to indicate null attributes, instead of the old convention of "char" arrays containing either 'n' or ' '. This provides a better match to the convention used by ExecEvalExpr. While I have not made a concerted effort to get rid of uses of the old routines, I think they should be deprecated and eventually removed.
2005-03-16 22:38:10 +01:00
isnull[lfirst_int(lc)] = true;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Process supplied expressions to replace selected columns.
* Expression inputs come from the old tuple.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
ExecStoreTuple(tuple, oldslot, InvalidBuffer, false);
econtext->ecxt_scantuple = oldslot;
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
foreach(l, tab->newvals)
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
NewColumnValue *ex = lfirst(l);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
values[ex->attnum - 1] = ExecEvalExpr(ex->exprstate,
econtext,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
&isnull[ex->attnum - 1],
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
NULL);
}
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
ALTER TABLE ADD COLUMN exhibits a significant memory leak when adding a column with a default expression. In that situation, we need to rewrite the heap relation. To evaluate the new default expression, we use ExecEvalExpr(); however, this can allocate memory in the current memory context, and ATRewriteTable() does not switch out of the active portal's heap memory context. The end result is a rather large memory leak (on the order of gigabytes for a reasonably sized table). This patch changes ATRewriteTable() to switch to the per-tuple memory context before beginning the per-tuple loop. It also removes an explicit heap_freetuple() in the loop, since that is no longer needed. In an unrelated change, I noticed the code was scanning through the attributes of the new tuple descriptor for each tuple of the old table. I changed this to use precomputation, which should slightly speed up the loop. Thanks to steve@deefs.net for reporting the leak.
2005-02-10 00:17:26 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Form the new tuple. Note that we don't explicitly pfree it,
* since the per-tuple memory context will be reset shortly.
ALTER TABLE ADD COLUMN exhibits a significant memory leak when adding a column with a default expression. In that situation, we need to rewrite the heap relation. To evaluate the new default expression, we use ExecEvalExpr(); however, this can allocate memory in the current memory context, and ATRewriteTable() does not switch out of the active portal's heap memory context. The end result is a rather large memory leak (on the order of gigabytes for a reasonably sized table). This patch changes ATRewriteTable() to switch to the per-tuple memory context before beginning the per-tuple loop. It also removes an explicit heap_freetuple() in the loop, since that is no longer needed. In an unrelated change, I noticed the code was scanning through the attributes of the new tuple descriptor for each tuple of the old table. I changed this to use precomputation, which should slightly speed up the loop. Thanks to steve@deefs.net for reporting the leak.
2005-02-10 00:17:26 +01:00
*/
Revise TupleTableSlot code to avoid unnecessary construction and disassembly of tuples when passing data up through multiple plan nodes. A slot can now hold either a normal "physical" HeapTuple, or a "virtual" tuple consisting of Datum/isnull arrays. Upper plan levels can usually just copy the Datum arrays, avoiding heap_formtuple() and possible subsequent nocachegetattr() calls to extract the data again. This work extends Atsushi Ogawa's earlier patch, which provided the key idea of adding Datum arrays to TupleTableSlots. (I believe however that something like this was foreseen way back in Berkeley days --- see the old comment on ExecProject.) A test case involving many levels of join of fairly wide tables (about 80 columns altogether) showed about 3x overall speedup, though simple queries will probably not be helped very much. I have also duplicated some code in heaptuple.c in order to provide versions of heap_formtuple and friends that use "bool" arrays to indicate null attributes, instead of the old convention of "char" arrays containing either 'n' or ' '. This provides a better match to the convention used by ExecEvalExpr. While I have not made a concerted effort to get rid of uses of the old routines, I think they should be deprecated and eventually removed.
2005-03-16 22:38:10 +01:00
tuple = heap_form_tuple(newTupDesc, values, isnull);
Preserve tuple OIDs during ATRewriteTable. Per gripe from Duncan Crombie.
2005-10-03 04:45:12 +02:00
/* Preserve OID, if any */
if (newTupDesc->tdhasoid)
HeapTupleSetOid(tuple, tupOid);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Now check any constraints on the possibly-changed tuple */
ExecStoreTuple(tuple, newslot, InvalidBuffer, false);
econtext->ecxt_scantuple = newslot;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
Fix ALTER TABLE to check pre-existing NOT NULL constraints when rewriting 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.
2006-07-11 00:10:39 +02:00
foreach(l, notnull_attrs)
{
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
int attn = lfirst_int(l);
Fix ALTER TABLE to check pre-existing NOT NULL constraints when rewriting 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.
2006-07-11 00:10:39 +02:00
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
if (heap_attisnull(tuple, attn + 1))
Fix ALTER TABLE to check pre-existing NOT NULL constraints when rewriting 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.
2006-07-11 00:10:39 +02:00
ereport(ERROR,
(errcode(ERRCODE_NOT_NULL_VIOLATION),
errmsg("column \"%s\" contains null values",
pgindent run for release 9.3 This is the first run of the Perl-based pgindent script. Also update pgindent instructions.
2013-05-29 22:58:43 +02:00
NameStr(newTupDesc->attrs[attn]->attname)),
Provide database object names as separate fields in error messages. This patch addresses the problem that applications currently have to extract object names from possibly-localized textual error messages, if they want to know for example which index caused a UNIQUE_VIOLATION failure. It adds new error message fields to the wire protocol, which can carry the name of a table, table column, data type, or constraint associated with the error. (Since the protocol spec has always instructed clients to ignore unrecognized field types, this should not create any compatibility problem.) Support for providing these new fields has been added to just a limited set of error reports (mainly, those in the "integrity constraint violation" SQLSTATE class), but we will doubtless add them to more calls in future. Pavel Stehule, reviewed and extensively revised by Peter Geoghegan, with additional hacking by Tom Lane.
2013-01-29 23:06:26 +01:00
errtablecol(oldrel, attn + 1)));
Fix ALTER TABLE to check pre-existing NOT NULL constraints when rewriting 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.
2006-07-11 00:10:39 +02:00
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
foreach(l, tab->constraints)
{
NewConstraint *con = lfirst(l);
Add LOCK A,B,C functionality as LOCK A;LOCK B;LOCK C; as agreed. Neil Padgett
2001-08-04 21:39:00 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
switch (con->contype)
{
case CONSTR_CHECK:
if (!ExecQual(con->qualstate, econtext, true))
ereport(ERROR,
(errcode(ERRCODE_CHECK_VIOLATION),
errmsg("check constraint \"%s\" is violated by some row",
Provide database object names as separate fields in error messages. This patch addresses the problem that applications currently have to extract object names from possibly-localized textual error messages, if they want to know for example which index caused a UNIQUE_VIOLATION failure. It adds new error message fields to the wire protocol, which can carry the name of a table, table column, data type, or constraint associated with the error. (Since the protocol spec has always instructed clients to ignore unrecognized field types, this should not create any compatibility problem.) Support for providing these new fields has been added to just a limited set of error reports (mainly, those in the "integrity constraint violation" SQLSTATE class), but we will doubtless add them to more calls in future. Pavel Stehule, reviewed and extensively revised by Peter Geoghegan, with additional hacking by Tom Lane.
2013-01-29 23:06:26 +01:00
con->name),
errtableconstraint(oldrel, con->name)));
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
break;
case CONSTR_FOREIGN:
/* Nothing to do here */
break;
default:
elog(ERROR, "unrecognized constraint type: %d",
(int) con->contype);
}
}
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Write the tuple out to the new relation */
if (newrel)
Allow rewriting ALTER TABLE to skip WAL logging. Itagaki Takahiro, with small changes by me and Simon.
2009-11-04 13:24:23 +01:00
heap_insert(newrel, tuple, mycid, hi_options, bistate);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
ResetExprContext(econtext);
CHECK_FOR_INTERRUPTS();
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
}
ALTER TABLE ADD COLUMN exhibits a significant memory leak when adding a column with a default expression. In that situation, we need to rewrite the heap relation. To evaluate the new default expression, we use ExecEvalExpr(); however, this can allocate memory in the current memory context, and ATRewriteTable() does not switch out of the active portal's heap memory context. The end result is a rather large memory leak (on the order of gigabytes for a reasonably sized table). This patch changes ATRewriteTable() to switch to the per-tuple memory context before beginning the per-tuple loop. It also removes an explicit heap_freetuple() in the loop, since that is no longer needed. In an unrelated change, I noticed the code was scanning through the attributes of the new tuple descriptor for each tuple of the old table. I changed this to use precomputation, which should slightly speed up the loop. Thanks to steve@deefs.net for reporting the leak.
2005-02-10 00:17:26 +01:00
MemoryContextSwitchTo(oldCxt);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
heap_endscan(scan);
Fix problems with cached tuple descriptors disappearing while still in use 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
2006-06-16 20:42:24 +02:00
ExecDropSingleTupleTableSlot(oldslot);
ExecDropSingleTupleTableSlot(newslot);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
}
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
FreeExecutorState(estate);
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
heap_close(oldrel, NoLock);
if (newrel)
Allow rewriting ALTER TABLE to skip WAL logging. Itagaki Takahiro, with small changes by me and Simon.
2009-11-04 13:24:23 +01:00
{
FreeBulkInsertState(bistate);
/* If we skipped writing WAL, then we need to sync the heap. */
if (hi_options & HEAP_INSERT_SKIP_WAL)
heap_sync(newrel);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
heap_close(newrel, NoLock);
Allow rewriting ALTER TABLE to skip WAL logging. Itagaki Takahiro, with small changes by me and Simon.
2009-11-04 13:24:23 +01:00
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* ATGetQueueEntry: find or create an entry in the ALTER TABLE work queue
*/
static AlteredTableInfo *
ATGetQueueEntry(List **wqueue, Relation rel)
{
Oid relid = RelationGetRelid(rel);
AlteredTableInfo *tab;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *ltab;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
foreach(ltab, *wqueue)
{
tab = (AlteredTableInfo *) lfirst(ltab);
if (tab->relid == relid)
return tab;
}
Previous patch backed out. Here is a patch against CVS (without my earlier patch) to disallow LOCK x if x is a view. It does not use the SPI interface. -- Mark Hollomon
2000-09-12 06:33:18 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* Not there, so add it. Note that we make a copy of the relation's
* existing descriptor before anything interesting can happen to it.
*/
tab = (AlteredTableInfo *) palloc0(sizeof(AlteredTableInfo));
tab->relid = relid;
Fix a couple of oversights in new ALTER TABLE code that broke ALTER SET STATISTICS for functional indexes.
2004-05-09 00:46:29 +02:00
tab->relkind = rel->rd_rel->relkind;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
tab->oldDesc = CreateTupleDescCopy(RelationGetDescr(rel));
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*wqueue = lappend(*wqueue, tab);
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
return tab;
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
}
First phase of SCHEMA changes, concentrating on fixing the grammar and the parsetree representation. As yet we don't *do* anything with schema names, just drop 'em on the floor; but you can enter schema-compatible command syntax, and there's even a primitive CREATE SCHEMA command. No doc updates yet, except to note that you can now extract a field from a function-returning-row's result with (foo(...)).fieldname.
2002-03-21 17:02:16 +01:00
/*
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* ATSimplePermissions
*
* - Ensure that it is a relation (or possibly a view)
* - Ensure this user is the owner
* - Ensure that it is not a system table
First phase of SCHEMA changes, concentrating on fixing the grammar and the parsetree representation. As yet we don't *do* anything with schema names, just drop 'em on the floor; but you can enter schema-compatible command syntax, and there's even a primitive CREATE SCHEMA command. No doc updates yet, except to note that you can now extract a field from a function-returning-row's result with (foo(...)).fieldname.
2002-03-21 17:02:16 +01:00
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static void
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
ATSimplePermissions(Relation rel, int allowed_targets)
First phase of SCHEMA changes, concentrating on fixing the grammar and the parsetree representation. As yet we don't *do* anything with schema names, just drop 'em on the floor; but you can enter schema-compatible command syntax, and there's even a primitive CREATE SCHEMA command. No doc updates yet, except to note that you can now extract a field from a function-returning-row's result with (foo(...)).fieldname.
2002-03-21 17:02:16 +01:00
{
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
int actual_target;
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
switch (rel->rd_rel->relkind)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
case RELKIND_RELATION:
actual_target = ATT_TABLE;
break;
case RELKIND_VIEW:
actual_target = ATT_VIEW;
break;
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
case RELKIND_MATVIEW:
actual_target = ATT_MATVIEW;
break;
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
case RELKIND_INDEX:
actual_target = ATT_INDEX;
break;
case RELKIND_COMPOSITE_TYPE:
actual_target = ATT_COMPOSITE_TYPE;
break;
case RELKIND_FOREIGN_TABLE:
actual_target = ATT_FOREIGN_TABLE;
break;
default:
actual_target = 0;
break;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
Checking to decide whether relations are system relations now depends on the namespace not the name; pg_ is not a reserved prefix for table names anymore. From Fernando Nasser.
2002-04-12 22:38:31 +02:00
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
/* Wrong target type? */
if ((actual_target & allowed_targets) == 0)
ATWrongRelkindError(rel, allowed_targets);
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
/* Permissions checks */
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (!pg_class_ownercheck(RelationGetRelid(rel), GetUserId()))
Adjust 'permission denied' messages to be more useful and consistent.
2003-08-01 02:15:26 +02:00
aclcheck_error(ACLCHECK_NOT_OWNER, ACL_KIND_CLASS,
RelationGetRelationName(rel));
First phase of SCHEMA changes, concentrating on fixing the grammar and the parsetree representation. As yet we don't *do* anything with schema names, just drop 'em on the floor; but you can enter schema-compatible command syntax, and there's even a primitive CREATE SCHEMA command. No doc updates yet, except to note that you can now extract a field from a function-returning-row's result with (foo(...)).fieldname.
2002-03-21 17:02:16 +01:00
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
if (!allowSystemTableMods && IsSystemRelation(rel))
ereport(ERROR,
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
Adjust 'permission denied' messages to be more useful and consistent.
2003-08-01 02:15:26 +02:00
errmsg("permission denied: \"%s\" is a system catalog",
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
RelationGetRelationName(rel))));
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
/*
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
* ATWrongRelkindError
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
*
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
* Throw an error when a relation has been determined to be of the wrong
* type.
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
*/
static void
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
ATWrongRelkindError(Relation rel, int allowed_targets)
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
{
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
char *msg;
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
switch (allowed_targets)
{
case ATT_TABLE:
msg = _("\"%s\" is not a table");
break;
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
case ATT_TABLE | ATT_VIEW:
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
msg = _("\"%s\" is not a table or view");
break;
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
case ATT_TABLE | ATT_VIEW | ATT_MATVIEW | ATT_INDEX:
msg = _("\"%s\" is not a table, view, materialized view, or index");
break;
case ATT_TABLE | ATT_MATVIEW:
msg = _("\"%s\" is not a table or materialized view");
break;
case ATT_TABLE | ATT_MATVIEW | ATT_INDEX:
msg = _("\"%s\" is not a table, materialized view, or index");
break;
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
case ATT_TABLE | ATT_FOREIGN_TABLE:
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
msg = _("\"%s\" is not a table or foreign table");
break;
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
case ATT_TABLE | ATT_COMPOSITE_TYPE | ATT_FOREIGN_TABLE:
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
msg = _("\"%s\" is not a table, composite type, or foreign table");
break;
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
case ATT_TABLE | ATT_MATVIEW | ATT_INDEX | ATT_FOREIGN_TABLE:
msg = _("\"%s\" is not a table, materialized view, composite type, or foreign table");
break;
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
case ATT_VIEW:
msg = _("\"%s\" is not a view");
break;
case ATT_FOREIGN_TABLE:
msg = _("\"%s\" is not a foreign table");
break;
default:
/* shouldn't get here, add all necessary cases above */
msg = _("\"%s\" is of the wrong type");
break;
}
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg(msg, RelationGetRelationName(rel))));
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* ATSimpleRecursion
*
* Simple table recursion sufficient for most ALTER TABLE operations.
* All direct and indirect children are processed in an unspecified order.
* Note that if a child inherits from the original table via multiple
* inheritance paths, it will be visited just once.
*/
static void
ATSimpleRecursion(List **wqueue, Relation rel,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
AlterTableCmd *cmd, bool recurse, LOCKMODE lockmode)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
First phase of SCHEMA changes, concentrating on fixing the grammar and the parsetree representation. As yet we don't *do* anything with schema names, just drop 'em on the floor; but you can enter schema-compatible command syntax, and there's even a primitive CREATE SCHEMA command. No doc updates yet, except to note that you can now extract a field from a function-returning-row's result with (foo(...)).fieldname.
2002-03-21 17:02:16 +01:00
/*
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* Propagate to children if desired. Non-table relations never have
* children, so no need to search in that case.
First phase of SCHEMA changes, concentrating on fixing the grammar and the parsetree representation. As yet we don't *do* anything with schema names, just drop 'em on the floor; but you can enter schema-compatible command syntax, and there's even a primitive CREATE SCHEMA command. No doc updates yet, except to note that you can now extract a field from a function-returning-row's result with (foo(...)).fieldname.
2002-03-21 17:02:16 +01:00
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (recurse && rel->rd_rel->relkind == RELKIND_RELATION)
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
{
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Oid relid = RelationGetRelid(rel);
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *child;
List *children;
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
children = find_all_inheritors(relid, lockmode, NULL);
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* find_all_inheritors does the recursive search of the inheritance
* hierarchy, so all we have to do is process all of the relids in the
* list that it returns.
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*/
foreach(child, children)
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
{
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
Oid childrelid = lfirst_oid(child);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Relation childrel;
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (childrelid == relid)
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
continue;
Modify find_inheritance_children() and find_all_inheritors() to add the ability to lock relations as they scan pg_inherits, and to ignore any relations that have disappeared by the time we get lock on them. This makes uses of these functions safe against concurrent DROP operations on child tables: we will effectively ignore any just-dropped child, rather than possibly throwing an error as in recent bug report from Thomas Johansson (and similar past complaints). The behavior should not change otherwise, since the code was acquiring those same locks anyway, just a little bit later. An exception is LockTableCommand(), which is still behaving unsafely; but that seems to require some more discussion before we change it.
2009-05-12 05:11:02 +02:00
/* find_all_inheritors already got lock */
childrel = relation_open(childrelid, NoLock);
Add checks to TRUNCATE, CLUSTER, and REINDEX to prevent performing these operations when the current transaction has any open references to the target relation or index (implying it has an active query using the relation). The need for this was previously recognized in connection with ALTER TABLE, but anything that summarily eliminates tuples or moves them around would confuse an active scan. While this patch does not in itself fix bug #3883 (the deadlock would happen before the new check fires), it will discourage people from attempting the sequence of operations that creates a deadlock risk, so it's at least a partial response to that problem. In passing, add a previously-missing check to REINDEX to prevent trying to reindex another backend's temp table. This isn't a security problem since only a superuser would get past the schema permission checks, but if we are testing for this in other utility commands then surely REINDEX should too.
2008-01-30 20:46:48 +01:00
CheckTableNotInUse(childrel, "ALTER TABLE");
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATPrepCmd(wqueue, childrel, cmd, false, true, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
relation_close(childrel, NoLock);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
}
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
/*
* ATTypedTableRecursion
*
* Propagate ALTER TYPE operations to the typed tables of that type.
Allow ALTER TYPE .. ADD ATTRIBUTE .. CASCADE to recurse to descendants. Without this, adding an attribute to a typed table with an inheritance child fails, which is surprising. Noah Misch, with minor changes by me.
2011-04-21 04:49:37 +02:00
* Also check the RESTRICT/CASCADE behavior. Given CASCADE, also permit
* recursion to inheritance children of the typed tables.
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
*/
static void
ATTypedTableRecursion(List **wqueue, Relation rel, AlterTableCmd *cmd,
LOCKMODE lockmode)
{
ListCell *child;
List *children;
Assert(rel->rd_rel->relkind == RELKIND_COMPOSITE_TYPE);
children = find_typed_table_dependencies(rel->rd_rel->reltype,
RelationGetRelationName(rel),
cmd->behavior);
foreach(child, children)
{
Oid childrelid = lfirst_oid(child);
Relation childrel;
childrel = relation_open(childrelid, lockmode);
CheckTableNotInUse(childrel, "ALTER TABLE");
Allow ALTER TYPE .. ADD ATTRIBUTE .. CASCADE to recurse to descendants. Without this, adding an attribute to a typed table with an inheritance child fails, which is surprising. Noah Misch, with minor changes by me.
2011-04-21 04:49:37 +02:00
ATPrepCmd(wqueue, childrel, cmd, true, true, lockmode);
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
relation_close(childrel, NoLock);
}
}
Allow use of table rowtypes directly as column types of other tables. Instead of prohibiting that, put code into ALTER TABLE to reject ALTERs that would affect other tables' columns. Eventually we will probably want to extend ALTER TABLE to actually do something useful here, but in the meantime it seems wrong to forbid the feature completely just because ALTER isn't fully baked.
2004-06-06 22:30:07 +02:00
/*
* find_composite_type_dependencies
*
Fix my oversight in enabling domains-of-domains: ALTER DOMAIN ADD CONSTRAINT 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.
2007-05-11 22:17:15 +02:00
* Check to see if a composite type is being used as a column in some
Allow use of table rowtypes directly as column types of other tables. Instead of prohibiting that, put code into ALTER TABLE to reject ALTERs that would affect other tables' columns. Eventually we will probably want to extend ALTER TABLE to actually do something useful here, but in the meantime it seems wrong to forbid the feature completely just because ALTER isn't fully baked.
2004-06-06 22:30:07 +02:00
* other table (possibly nested several levels deep in composite types!).
* Eventually, we'd like to propagate the check or rewrite operation
* into other such tables, but for now, just error out if we find any.
*
Fix my oversight in enabling domains-of-domains: ALTER DOMAIN ADD CONSTRAINT 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.
2007-05-11 22:17:15 +02:00
* Caller should provide either a table name or a type name (not both) to
* report in the error message, if any.
*
Allow use of table rowtypes directly as column types of other tables. Instead of prohibiting that, put code into ALTER TABLE to reject ALTERs that would affect other tables' columns. Eventually we will probably want to extend ALTER TABLE to actually do something useful here, but in the meantime it seems wrong to forbid the feature completely just because ALTER isn't fully baked.
2004-06-06 22:30:07 +02:00
* We assume that functions and views depending on the type are not reasons
* to reject the ALTER. (How safe is this really?)
*/
Fix my oversight in enabling domains-of-domains: ALTER DOMAIN ADD CONSTRAINT 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.
2007-05-11 22:17:15 +02:00
void
Tweak find_composite_type_dependencies API a bit more. 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.
2011-02-11 14:47:38 +01:00
find_composite_type_dependencies(Oid typeOid, Relation origRelation,
const char *origTypeName)
Allow use of table rowtypes directly as column types of other tables. Instead of prohibiting that, put code into ALTER TABLE to reject ALTERs that would affect other tables' columns. Eventually we will probably want to extend ALTER TABLE to actually do something useful here, but in the meantime it seems wrong to forbid the feature completely just because ALTER isn't fully baked.
2004-06-06 22:30:07 +02:00
{
Relation depRel;
ScanKeyData key[2];
SysScanDesc depScan;
HeapTuple depTup;
Support arrays of composite types, including the rowtypes of regular tables 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
2007-05-11 19:57:14 +02:00
Oid arrayOid;
Allow use of table rowtypes directly as column types of other tables. Instead of prohibiting that, put code into ALTER TABLE to reject ALTERs that would affect other tables' columns. Eventually we will probably want to extend ALTER TABLE to actually do something useful here, but in the meantime it seems wrong to forbid the feature completely just because ALTER isn't fully baked.
2004-06-06 22:30:07 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* We scan pg_depend to find those things that depend on the rowtype. (We
* assume we can ignore refobjsubid for a rowtype.)
Allow use of table rowtypes directly as column types of other tables. Instead of prohibiting that, put code into ALTER TABLE to reject ALTERs that would affect other tables' columns. Eventually we will probably want to extend ALTER TABLE to actually do something useful here, but in the meantime it seems wrong to forbid the feature completely just because ALTER isn't fully baked.
2004-06-06 22:30:07 +02:00
*/
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
depRel = heap_open(DependRelationId, AccessShareLock);
Allow use of table rowtypes directly as column types of other tables. Instead of prohibiting that, put code into ALTER TABLE to reject ALTERs that would affect other tables' columns. Eventually we will probably want to extend ALTER TABLE to actually do something useful here, but in the meantime it seems wrong to forbid the feature completely just because ALTER isn't fully baked.
2004-06-06 22:30:07 +02:00
ScanKeyInit(&key[0],
Anum_pg_depend_refclassid,
BTEqualStrategyNumber, F_OIDEQ,
First phase of project to use fixed OIDs for all system catalogs and indexes. Extend the macros in include/catalog/*.h to carry the info about hand-assigned OIDs, and adjust the genbki script and bootstrap code to make the relations actually get those OIDs. Remove the small number of RelOid_pg_foo macros that we had in favor of a complete set named like the catname.h and indexing.h macros. Next phase will get rid of internal use of names for looking up catalogs and indexes; but this completes the changes forcing an initdb, so it looks like a good place to commit. Along the way, I made the shared relations (pg_database etc) not be 'bootstrap' relations any more, so as to reduce the number of hardwired entries and simplify changing those relations in future. I'm not sure whether they ever really needed to be handled as bootstrap relations, but it seems to work fine to not do so now.
2005-04-14 03:38:22 +02:00
ObjectIdGetDatum(TypeRelationId));
Allow use of table rowtypes directly as column types of other tables. Instead of prohibiting that, put code into ALTER TABLE to reject ALTERs that would affect other tables' columns. Eventually we will probably want to extend ALTER TABLE to actually do something useful here, but in the meantime it seems wrong to forbid the feature completely just because ALTER isn't fully baked.
2004-06-06 22:30:07 +02:00
ScanKeyInit(&key[1],
Anum_pg_depend_refobjid,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(typeOid));
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
depScan = systable_beginscan(depRel, DependReferenceIndexId, true,
Allow use of table rowtypes directly as column types of other tables. Instead of prohibiting that, put code into ALTER TABLE to reject ALTERs that would affect other tables' columns. Eventually we will probably want to extend ALTER TABLE to actually do something useful here, but in the meantime it seems wrong to forbid the feature completely just because ALTER isn't fully baked.
2004-06-06 22:30:07 +02:00
SnapshotNow, 2, key);
while (HeapTupleIsValid(depTup = systable_getnext(depScan)))
{
Form_pg_depend pg_depend = (Form_pg_depend) GETSTRUCT(depTup);
Relation rel;
Form_pg_attribute att;
/* Ignore dependees that aren't user columns of relations */
/* (we assume system columns are never of rowtypes) */
First phase of project to use fixed OIDs for all system catalogs and indexes. Extend the macros in include/catalog/*.h to carry the info about hand-assigned OIDs, and adjust the genbki script and bootstrap code to make the relations actually get those OIDs. Remove the small number of RelOid_pg_foo macros that we had in favor of a complete set named like the catname.h and indexing.h macros. Next phase will get rid of internal use of names for looking up catalogs and indexes; but this completes the changes forcing an initdb, so it looks like a good place to commit. Along the way, I made the shared relations (pg_database etc) not be 'bootstrap' relations any more, so as to reduce the number of hardwired entries and simplify changing those relations in future. I'm not sure whether they ever really needed to be handled as bootstrap relations, but it seems to work fine to not do so now.
2005-04-14 03:38:22 +02:00
if (pg_depend->classid != RelationRelationId ||
Allow use of table rowtypes directly as column types of other tables. Instead of prohibiting that, put code into ALTER TABLE to reject ALTERs that would affect other tables' columns. Eventually we will probably want to extend ALTER TABLE to actually do something useful here, but in the meantime it seems wrong to forbid the feature completely just because ALTER isn't fully baked.
2004-06-06 22:30:07 +02:00
pg_depend->objsubid <= 0)
continue;
rel = relation_open(pg_depend->objid, AccessShareLock);
att = rel->rd_att->attrs[pg_depend->objsubid - 1];
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
if (rel->rd_rel->relkind == RELKIND_RELATION ||
rel->rd_rel->relkind == RELKIND_MATVIEW)
Allow use of table rowtypes directly as column types of other tables. Instead of prohibiting that, put code into ALTER TABLE to reject ALTERs that would affect other tables' columns. Eventually we will probably want to extend ALTER TABLE to actually do something useful here, but in the meantime it seems wrong to forbid the feature completely just because ALTER isn't fully baked.
2004-06-06 22:30:07 +02:00
{
Clean up overly complex code for issuing some related error messages. The original version was unreadable, and not mechanically checkable either.
2011-03-29 23:54:27 +02:00
if (origTypeName)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
Message style and spelling improvements
2011-06-21 23:33:20 +02:00
errmsg("cannot alter type \"%s\" because column \"%s.%s\" uses it",
Clean up overly complex code for issuing some related error messages. The original version was unreadable, and not mechanically checkable either.
2011-03-29 23:54:27 +02:00
origTypeName,
RelationGetRelationName(rel),
NameStr(att->attname))));
else if (origRelation->rd_rel->relkind == RELKIND_COMPOSITE_TYPE)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
Message style and spelling improvements
2011-06-21 23:33:20 +02:00
errmsg("cannot alter type \"%s\" because column \"%s.%s\" uses it",
Clean up overly complex code for issuing some related error messages. The original version was unreadable, and not mechanically checkable either.
2011-03-29 23:54:27 +02:00
RelationGetRelationName(origRelation),
RelationGetRelationName(rel),
NameStr(att->attname))));
Tweak find_composite_type_dependencies API a bit more. 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.
2011-02-11 14:47:38 +01:00
else if (origRelation->rd_rel->relkind == RELKIND_FOREIGN_TABLE)
Clean up overly complex code for issuing some related error messages. The original version was unreadable, and not mechanically checkable either.
2011-03-29 23:54:27 +02:00
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
Message style and spelling improvements
2011-06-21 23:33:20 +02:00
errmsg("cannot alter foreign table \"%s\" because column \"%s.%s\" uses its row type",
Clean up overly complex code for issuing some related error messages. The original version was unreadable, and not mechanically checkable either.
2011-03-29 23:54:27 +02:00
RelationGetRelationName(origRelation),
RelationGetRelationName(rel),
NameStr(att->attname))));
Fix my oversight in enabling domains-of-domains: ALTER DOMAIN ADD CONSTRAINT 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.
2007-05-11 22:17:15 +02:00
else
Clean up overly complex code for issuing some related error messages. The original version was unreadable, and not mechanically checkable either.
2011-03-29 23:54:27 +02:00
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
Message style and spelling improvements
2011-06-21 23:33:20 +02:00
errmsg("cannot alter table \"%s\" because column \"%s.%s\" uses its row type",
Clean up overly complex code for issuing some related error messages. The original version was unreadable, and not mechanically checkable either.
2011-03-29 23:54:27 +02:00
RelationGetRelationName(origRelation),
RelationGetRelationName(rel),
NameStr(att->attname))));
Allow use of table rowtypes directly as column types of other tables. Instead of prohibiting that, put code into ALTER TABLE to reject ALTERs that would affect other tables' columns. Eventually we will probably want to extend ALTER TABLE to actually do something useful here, but in the meantime it seems wrong to forbid the feature completely just because ALTER isn't fully baked.
2004-06-06 22:30:07 +02:00
}
else if (OidIsValid(rel->rd_rel->reltype))
{
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* A view or composite type itself isn't a problem, but we must
* recursively check for indirect dependencies via its rowtype.
Allow use of table rowtypes directly as column types of other tables. Instead of prohibiting that, put code into ALTER TABLE to reject ALTERs that would affect other tables' columns. Eventually we will probably want to extend ALTER TABLE to actually do something useful here, but in the meantime it seems wrong to forbid the feature completely just because ALTER isn't fully baked.
2004-06-06 22:30:07 +02:00
*/
find_composite_type_dependencies(rel->rd_rel->reltype,
Tweak find_composite_type_dependencies API a bit more. 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.
2011-02-11 14:47:38 +01:00
origRelation, origTypeName);
Allow use of table rowtypes directly as column types of other tables. Instead of prohibiting that, put code into ALTER TABLE to reject ALTERs that would affect other tables' columns. Eventually we will probably want to extend ALTER TABLE to actually do something useful here, but in the meantime it seems wrong to forbid the feature completely just because ALTER isn't fully baked.
2004-06-06 22:30:07 +02:00
}
relation_close(rel, AccessShareLock);
}
systable_endscan(depScan);
relation_close(depRel, AccessShareLock);
Support arrays of composite types, including the rowtypes of regular tables 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
2007-05-11 19:57:14 +02:00
/*
* If there's an array type for the rowtype, must check for uses of it,
* too.
*/
arrayOid = get_array_type(typeOid);
if (OidIsValid(arrayOid))
Tweak find_composite_type_dependencies API a bit more. 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.
2011-02-11 14:47:38 +01:00
find_composite_type_dependencies(arrayOid, origRelation, origTypeName);
Allow use of table rowtypes directly as column types of other tables. Instead of prohibiting that, put code into ALTER TABLE to reject ALTERs that would affect other tables' columns. Eventually we will probably want to extend ALTER TABLE to actually do something useful here, but in the meantime it seems wrong to forbid the feature completely just because ALTER isn't fully baked.
2004-06-06 22:30:07 +02:00
}
Add ALTER TYPE ... ADD/DROP/ALTER/RENAME ATTRIBUTE Like with tables, this also requires allowing the existence of composite types with zero attributes. reviewed by KaiGai Kohei
2010-09-26 13:41:03 +02:00
/*
* find_typed_table_dependencies
*
* Check to see if a composite type is being used as the type of a
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
* typed table. Abort if any are found and behavior is RESTRICT.
* Else return the list of tables.
Add ALTER TYPE ... ADD/DROP/ALTER/RENAME ATTRIBUTE Like with tables, this also requires allowing the existence of composite types with zero attributes. reviewed by KaiGai Kohei
2010-09-26 13:41:03 +02:00
*/
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
static List *
find_typed_table_dependencies(Oid typeOid, const char *typeName, DropBehavior behavior)
Add ALTER TYPE ... ADD/DROP/ALTER/RENAME ATTRIBUTE Like with tables, this also requires allowing the existence of composite types with zero attributes. reviewed by KaiGai Kohei
2010-09-26 13:41:03 +02:00
{
Relation classRel;
ScanKeyData key[1];
HeapScanDesc scan;
HeapTuple tuple;
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
List *result = NIL;
Add ALTER TYPE ... ADD/DROP/ALTER/RENAME ATTRIBUTE Like with tables, this also requires allowing the existence of composite types with zero attributes. reviewed by KaiGai Kohei
2010-09-26 13:41:03 +02:00
classRel = heap_open(RelationRelationId, AccessShareLock);
ScanKeyInit(&key[0],
Anum_pg_class_reloftype,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(typeOid));
scan = heap_beginscan(classRel, SnapshotNow, 1, key);
Fix bug in propagating ALTER TABLE actions to typed tables. We need to propagate such actions to all typed table children of a given type, not just the first one. Noah Misch
2011-04-08 21:44:50 +02:00
while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
Add ALTER TYPE ... ADD/DROP/ALTER/RENAME ATTRIBUTE Like with tables, this also requires allowing the existence of composite types with zero attributes. reviewed by KaiGai Kohei
2010-09-26 13:41:03 +02:00
{
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
if (behavior == DROP_RESTRICT)
ereport(ERROR,
(errcode(ERRCODE_DEPENDENT_OBJECTS_STILL_EXIST),
errmsg("cannot alter type \"%s\" because it is the type of a typed table",
typeName),
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
errhint("Use ALTER ... CASCADE to alter the typed tables too.")));
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
else
result = lappend_oid(result, HeapTupleGetOid(tuple));
Add ALTER TYPE ... ADD/DROP/ALTER/RENAME ATTRIBUTE Like with tables, this also requires allowing the existence of composite types with zero attributes. reviewed by KaiGai Kohei
2010-09-26 13:41:03 +02:00
}
heap_endscan(scan);
heap_close(classRel, AccessShareLock);
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
return result;
Add ALTER TYPE ... ADD/DROP/ALTER/RENAME ATTRIBUTE Like with tables, this also requires allowing the existence of composite types with zero attributes. reviewed by KaiGai Kohei
2010-09-26 13:41:03 +02:00
}
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
/*
* check_of_type
*
* Check whether a type is suitable for CREATE TABLE OF/ALTER TABLE OF. If it
* isn't suitable, throw an error. Currently, we require that the type
Pgindent run before 9.1 beta2.
2011-06-09 20:32:50 +02:00
* originated with CREATE TYPE AS. We could support any row type, but doing so
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
* would require handling a number of extra corner cases in the DDL commands.
*/
void
check_of_type(HeapTuple typetuple)
{
Form_pg_type typ = (Form_pg_type) GETSTRUCT(typetuple);
bool typeOk = false;
if (typ->typtype == TYPTYPE_COMPOSITE)
{
Relation typeRelation;
Assert(OidIsValid(typ->typrelid));
typeRelation = relation_open(typ->typrelid, AccessShareLock);
typeOk = (typeRelation->rd_rel->relkind == RELKIND_COMPOSITE_TYPE);
Pgindent run before 9.1 beta2.
2011-06-09 20:32:50 +02:00
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
/*
* Close the parent rel, but keep our AccessShareLock on it until xact
* commit. That will prevent someone else from deleting or ALTERing
* the type before the typed table creation/conversion commits.
*/
relation_close(typeRelation, NoLock);
}
if (!typeOk)
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("type %s is not a composite type",
format_type_be(HeapTupleGetOid(typetuple)))));
}
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
/*
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* ALTER TABLE ADD COLUMN
*
* Adds an additional attribute to a relation making the assumption that
* CHECK, NOT NULL, and FOREIGN KEY constraints will be removed from the
Separate parse-analysis for utility commands out of parser/analyze.c (which now deals only in optimizable statements), and put that code into a new file parser/parse_utilcmd.c. This helps clarify and enforce the design rule that utility statements shouldn't be processed during the regular parse analysis phase; all interpretation of their meaning should happen after they are given to ProcessUtility to execute. (We need this because we don't retain any locks for a utility statement that's in a plan cache, nor have any way to detect that it's stale.) We are also able to simplify the API for parse_analyze() and related routines, because they will now always return exactly one Query structure. In passing, fix bug #3403 concerning trying to add a serial column to an existing temp table (this is largely Heikki's work, but we needed all that restructuring to make it safe).
2007-06-24 00:12:52 +02:00
* AT_AddColumn AlterTableCmd by parse_utilcmd.c and added as independent
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* AlterTableCmd's.
Rearrange "add column" logic to merge columns at exec time. 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.
2011-04-04 03:52:47 +02:00
*
* ADD COLUMN cannot use the normal ALTER TABLE recursion mechanism, because we
* have to decide at runtime whether to recurse or not depending on whether we
* actually add a column or merely merge with an existing column. (We can't
* check this in a static pre-pass because it won't handle multiple inheritance
* situations correctly.)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
static void
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
ATPrepAddColumn(List **wqueue, Relation rel, bool recurse, bool recursing,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
AlterTableCmd *cmd, LOCKMODE lockmode)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
if (rel->rd_rel->reloftype && !recursing)
Add more checks against altering typed tables - Prohibit altering column type - Prohibit changing inheritance - Move checks from Exec to Prep phases in ALTER TABLE code backpatched to 9.0
2010-07-23 22:04:18 +02:00
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("cannot add column to typed table")));
Add ALTER TYPE ... ADD/DROP/ALTER/RENAME ATTRIBUTE Like with tables, this also requires allowing the existence of composite types with zero attributes. reviewed by KaiGai Kohei
2010-09-26 13:41:03 +02:00
if (rel->rd_rel->relkind == RELKIND_COMPOSITE_TYPE)
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
ATTypedTableRecursion(wqueue, rel, cmd, lockmode);
Rearrange "add column" logic to merge columns at exec time. 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.
2011-04-04 03:52:47 +02:00
if (recurse)
cmd->subtype = AT_AddColumnRecurse;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static void
Rearrange "add column" logic to merge columns at exec time. 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.
2011-04-04 03:52:47 +02:00
ATExecAddColumn(List **wqueue, AlteredTableInfo *tab, Relation rel,
ColumnDef *colDef, bool isOid,
bool recurse, bool recursing, LOCKMODE lockmode)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
Oid myrelid = RelationGetRelid(rel);
Relation pgclass,
attrdesc;
HeapTuple reltup;
Replace the usage of heap_addheader to create pg_attribute tuples with regular heap_form_tuple. Since this removes the last remaining caller of heap_addheader, remove it. Extracted from the column privileges patch from Stephen Frost, with further code cleanups by me.
2008-11-14 02:57:42 +01:00
FormData_pg_attribute attribute;
Code review for CREATE OR REPLACE VIEW patch. Do things in a saner order to result in hopefully-less-confusing error messages when the new definition isn't compatible with the old; minor other cleanup.
2008-12-15 22:35:31 +01:00
int newattnum;
Allow CREATE OR REPLACE VIEW to add columns to the _end_ of the view. Robert Haas
2008-12-07 00:22:46 +01:00
char relkind;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
HeapTuple typeTuple;
Fix ALTER TABLE ADD COLUMN so that constraints of domain types are enforced properly when there is no explicit default value for the new column. Per report from Craig Perras.
2005-01-25 00:21:57 +01:00
Oid typeOid;
Support type modifiers for user-defined types, and pull most knowledge about typmod representation for standard types out into type-specific typmod I/O functions. Teodor Sigaev, with some editorialization by Tom Lane.
2006-12-30 22:21:56 +01:00
int32 typmod;
Per-column collation support 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
2011-02-08 22:04:18 +01:00
Oid collOid;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Form_pg_type tform;
Expr *defval;
Rearrange "add column" logic to merge columns at exec time. 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.
2011-04-04 03:52:47 +02:00
List *children;
ListCell *child;
Add support for privileges on types This adds support for the more or less SQL-conforming USAGE privilege on types and domains. The intent is to be able restrict which users can create dependencies on types, which restricts the way in which owners can alter types. reviewed by Yeb Havinga
2011-12-19 23:05:19 +01:00
AclResult aclresult;
Rearrange "add column" logic to merge columns at exec time. 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.
2011-04-04 03:52:47 +02:00
/* At top level, permission check was done in ATPrepCmd, else do it */
if (recursing)
ATSimplePermissions(rel, ATT_TABLE);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
attrdesc = heap_open(AttributeRelationId, RowExclusiveLock);
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Are we adding the column to a recursion child? If so, check whether to
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
* merge with an existing definition for the column. If we do merge, we
* must not recurse. Children will already have the column, and recursing
* into them would mess up attinhcount.
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (colDef->inhcount > 0)
{
HeapTuple tuple;
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Does child already have a column by this name? */
tuple = SearchSysCacheCopyAttName(myrelid, colDef->colname);
if (HeapTupleIsValid(tuple))
{
Form_pg_attribute childatt = (Form_pg_attribute) GETSTRUCT(tuple);
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
Oid ctypeId;
int32 ctypmod;
Per-column collation support 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
2011-02-08 22:04:18 +01:00
Oid ccollid;
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Add check for matching column collations in ALTER TABLE ... INHERIT. 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.
2011-04-17 22:22:13 +02:00
/* Child column must match on type, typmod, and collation */
Remove collation information from TypeName, where it does not belong. 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.
2011-03-10 04:38:52 +01:00
typenameTypeIdAndMod(NULL, colDef->typeName, &ctypeId, &ctypmod);
Support type modifiers for user-defined types, and pull most knowledge about typmod representation for standard types out into type-specific typmod I/O functions. Teodor Sigaev, with some editorialization by Tom Lane.
2006-12-30 22:21:56 +01:00
if (ctypeId != childatt->atttypid ||
ctypmod != childatt->atttypmod)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("child table \"%s\" has different type for column \"%s\"",
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
RelationGetRelationName(rel), colDef->colname)));
Remove collation information from TypeName, where it does not belong. 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.
2011-03-10 04:38:52 +01:00
ccollid = GetColumnDefCollation(NULL, colDef, ctypeId);
Per-column collation support 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
2011-02-08 22:04:18 +01:00
if (ccollid != childatt->attcollation)
ereport(ERROR,
(errcode(ERRCODE_COLLATION_MISMATCH),
errmsg("child table \"%s\" has different collation for column \"%s\"",
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
RelationGetRelationName(rel), colDef->colname),
Per-column collation support 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
2011-02-08 22:04:18 +01:00
errdetail("\"%s\" versus \"%s\"",
get_collation_name(ccollid),
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
get_collation_name(childatt->attcollation))));
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
/* If it's OID, child column must actually be OID */
if (isOid && childatt->attnum != ObjectIdAttributeNumber)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
errmsg("child table \"%s\" has a conflicting \"%s\" column",
RelationGetRelationName(rel), colDef->colname)));
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Bump the existing child att's inhcount */
childatt->attinhcount++;
simple_heap_update(attrdesc, &tuple->t_self, tuple);
CatalogUpdateIndexes(attrdesc, tuple);
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
heap_freetuple(tuple);
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Inform the user about the merge */
ereport(NOTICE,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
(errmsg("merging definition of column \"%s\" for child \"%s\"",
colDef->colname, RelationGetRelationName(rel))));
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
heap_close(attrdesc, RowExclusiveLock);
return;
}
}
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
pgclass = heap_open(RelationRelationId, RowExclusiveLock);
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Wrap calls to SearchSysCache and related functions using macros. The purpose of this change is to eliminate the need for every caller of SearchSysCache, SearchSysCacheCopy, SearchSysCacheExists, GetSysCacheOid, and SearchSysCacheList to know the maximum number of allowable keys for a syscache entry (currently 4). This will make it far easier to increase the maximum number of keys in a future release should we choose to do so, and it makes the code shorter, too. Design and review by Tom Lane.
2010-02-14 19:42:19 +01:00
reltup = SearchSysCacheCopy1(RELOID, ObjectIdGetDatum(myrelid));
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (!HeapTupleIsValid(reltup))
elog(ERROR, "cache lookup failed for relation %u", myrelid);
Code review for CREATE OR REPLACE VIEW patch. Do things in a saner order to result in hopefully-less-confusing error messages when the new definition isn't compatible with the old; minor other cleanup.
2008-12-15 22:35:31 +01:00
relkind = ((Form_pg_class) GETSTRUCT(reltup))->relkind;
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Be more clear when a new column name collides with a system column name. We now use the same error message for ALTER TABLE .. ADD COLUMN or ALTER TABLE .. RENAME COLUMN that we do for CREATE TABLE. The old message was accurate, but might be confusing to users not aware of our system columns. Vik Reykja, with some changes by me, and further proofreading by Tom Lane
2012-01-26 18:44:30 +01:00
/* new name should not already exist */
check_for_column_name_collision(rel, colDef->colname);
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
/* Determine the new attribute's number */
if (isOid)
newattnum = ObjectIdAttributeNumber;
else
{
newattnum = ((Form_pg_class) GETSTRUCT(reltup))->relnatts + 1;
if (newattnum > MaxHeapAttributeNumber)
ereport(ERROR,
(errcode(ERRCODE_TOO_MANY_COLUMNS),
errmsg("tables can have at most %d columns",
MaxHeapAttributeNumber)));
}
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
Remove collation information from TypeName, where it does not belong. 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.
2011-03-10 04:38:52 +01:00
typeTuple = typenameType(NULL, colDef->typeName, &typmod);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
tform = (Form_pg_type) GETSTRUCT(typeTuple);
Fix ALTER TABLE ADD COLUMN so that constraints of domain types are enforced properly when there is no explicit default value for the new column. Per report from Craig Perras.
2005-01-25 00:21:57 +01:00
typeOid = HeapTupleGetOid(typeTuple);
Add support for privileges on types This adds support for the more or less SQL-conforming USAGE privilege on types and domains. The intent is to be able restrict which users can create dependencies on types, which restricts the way in which owners can alter types. reviewed by Yeb Havinga
2011-12-19 23:05:19 +01:00
aclresult = pg_type_aclcheck(typeOid, GetUserId(), ACL_USAGE);
if (aclresult != ACLCHECK_OK)
Improve reporting of permission errors for array types Because permissions are assigned to element types, not array types, complaining about permission denied on an array type would be misleading to users. So adjust the reporting to refer to the element type instead. In order not to duplicate the required logic in two dozen places, refactor the permission denied reporting for types a bit. pointed out by Yeb Havinga during the review of the type privilege feature
2012-06-15 21:55:03 +02:00
aclcheck_error_type(aclresult, typeOid);
Add support for privileges on types This adds support for the more or less SQL-conforming USAGE privilege on types and domains. The intent is to be able restrict which users can create dependencies on types, which restricts the way in which owners can alter types. reviewed by Yeb Havinga
2011-12-19 23:05:19 +01:00
Remove collation information from TypeName, where it does not belong. 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.
2011-03-10 04:38:52 +01:00
collOid = GetColumnDefCollation(NULL, colDef, typeOid);
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* make sure datatype is legal for a column */
Prevent a rowtype from being included in itself. 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.
2011-03-28 21:44:54 +02:00
CheckAttributeType(colDef->colname, typeOid, collOid,
list_make1_oid(rel->rd_rel->reltype),
false);
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Code review for CREATE OR REPLACE VIEW patch. Do things in a saner order to result in hopefully-less-confusing error messages when the new definition isn't compatible with the old; minor other cleanup.
2008-12-15 22:35:31 +01:00
/* construct new attribute's pg_attribute entry */
Replace the usage of heap_addheader to create pg_attribute tuples with regular heap_form_tuple. Since this removes the last remaining caller of heap_addheader, remove it. Extracted from the column privileges patch from Stephen Frost, with further code cleanups by me.
2008-11-14 02:57:42 +01:00
attribute.attrelid = myrelid;
namestrcpy(&(attribute.attname), colDef->colname);
attribute.atttypid = typeOid;
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
attribute.attstattarget = (newattnum > 0) ? -1 : 0;
Replace the usage of heap_addheader to create pg_attribute tuples with regular heap_form_tuple. Since this removes the last remaining caller of heap_addheader, remove it. Extracted from the column privileges patch from Stephen Frost, with further code cleanups by me.
2008-11-14 02:57:42 +01:00
attribute.attlen = tform->typlen;
attribute.attcacheoff = -1;
attribute.atttypmod = typmod;
Code review for CREATE OR REPLACE VIEW patch. Do things in a saner order to result in hopefully-less-confusing error messages when the new definition isn't compatible with the old; minor other cleanup.
2008-12-15 22:35:31 +01:00
attribute.attnum = newattnum;
Replace the usage of heap_addheader to create pg_attribute tuples with regular heap_form_tuple. Since this removes the last remaining caller of heap_addheader, remove it. Extracted from the column privileges patch from Stephen Frost, with further code cleanups by me.
2008-11-14 02:57:42 +01:00
attribute.attbyval = tform->typbyval;
Make backend header files C++ safe This alters various incidental uses of C++ key words to use other similar identifiers, so that a C++ compiler won't choke outright. You still (probably) need extern "C" { }; around the inclusion of backend headers. based on a patch by Kurt Harriman <harriman@acm.org> Also add a script cpluspluscheck to check for C++ compatibility in the future. As of right now, this passes without error for me.
2009-07-16 08:33:46 +02:00
attribute.attndims = list_length(colDef->typeName->arrayBounds);
Replace the usage of heap_addheader to create pg_attribute tuples with regular heap_form_tuple. Since this removes the last remaining caller of heap_addheader, remove it. Extracted from the column privileges patch from Stephen Frost, with further code cleanups by me.
2008-11-14 02:57:42 +01:00
attribute.attstorage = tform->typstorage;
attribute.attalign = tform->typalign;
attribute.attnotnull = colDef->is_not_null;
attribute.atthasdef = false;
attribute.attisdropped = false;
attribute.attislocal = colDef->is_local;
attribute.attinhcount = colDef->inhcount;
Per-column collation support 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
2011-02-08 22:04:18 +01:00
attribute.attcollation = collOid;
Support column-level privileges, as required by SQL standard. Stephen Frost, with help from KaiGai Kohei and others
2009-01-22 21:16:10 +01:00
/* attribute.attacl is handled by InsertPgAttributeTuple */
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
ReleaseSysCache(typeTuple);
Replace the usage of heap_addheader to create pg_attribute tuples with regular heap_form_tuple. Since this removes the last remaining caller of heap_addheader, remove it. Extracted from the column privileges patch from Stephen Frost, with further code cleanups by me.
2008-11-14 02:57:42 +01:00
InsertPgAttributeTuple(attrdesc, &attribute, NULL);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
heap_close(attrdesc, RowExclusiveLock);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
/*
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
* Update pg_class tuple as appropriate
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
*/
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
if (isOid)
((Form_pg_class) GETSTRUCT(reltup))->relhasoids = true;
else
((Form_pg_class) GETSTRUCT(reltup))->relnatts = newattnum;
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
simple_heap_update(pgclass, &reltup->t_self, reltup);
/* keep catalog indexes current */
CatalogUpdateIndexes(pgclass, reltup);
heap_freetuple(reltup);
Object access hook framework, with post-creation hook. After a SQL object is created, we provide an opportunity for security or logging plugins to get control; for example, a security label provider could use this to assign an initial security label to newly created objects. The basic infrastructure is (hopefully) reusable for other types of events that might require similar treatment. KaiGai Kohei, with minor adjustments.
2010-11-25 17:48:49 +01:00
/* Post creation hook for new attribute */
Code beautification for object-access hook machinery. KaiGai Kohei
2013-03-07 02:52:06 +01:00
InvokeObjectPostCreateHook(RelationRelationId, myrelid, newattnum);
Object access hook framework, with post-creation hook. After a SQL object is created, we provide an opportunity for security or logging plugins to get control; for example, a security label provider could use this to assign an initial security label to newly created objects. The basic infrastructure is (hopefully) reusable for other types of events that might require similar treatment. KaiGai Kohei, with minor adjustments.
2010-11-25 17:48:49 +01:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
heap_close(pgclass, RowExclusiveLock);
/* Make the attribute's catalog entry visible */
CommandCounterIncrement();
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
Use the dependency mechanism to manage column defaults. We need this so that dependencies in default expressions (on operators, functions, etc) can be expressed properly.
2002-07-15 18:33:32 +02:00
/*
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* Store the DEFAULT, if any, in the catalogs
Use the dependency mechanism to manage column defaults. We need this so that dependencies in default expressions (on operators, functions, etc) can be expressed properly.
2002-07-15 18:33:32 +02:00
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (colDef->raw_default)
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
{
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
RawColumnDefault *rawEnt;
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
rawEnt = (RawColumnDefault *) palloc(sizeof(RawColumnDefault));
Replace the usage of heap_addheader to create pg_attribute tuples with regular heap_form_tuple. Since this removes the last remaining caller of heap_addheader, remove it. Extracted from the column privileges patch from Stephen Frost, with further code cleanups by me.
2008-11-14 02:57:42 +01:00
rawEnt->attnum = attribute.attnum;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
rawEnt->raw_default = copyObject(colDef->raw_default);
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
* This function is intended for CREATE TABLE, so it processes a
* _list_ of defaults, but we just do one.
*/
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
AddRelationNewConstraints(rel, list_make1(rawEnt), NIL,
false, true, false);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Make the additional catalog changes visible */
CommandCounterIncrement();
}
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
First steps towards statistics on expressional (nee functional) indexes. This commit teaches ANALYZE to store such stats in pg_statistic, but nothing is done yet about teaching the planner to use 'em. Also, repair longstanding oversight in separate ANALYZE command: it updated the pg_class.relpages and reltuples counts for the table proper, but not for indexes.
2004-02-15 22:01:39 +01:00
/*
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* Tell Phase 3 to fill in the default expression, if there is one.
*
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
* If there is no default, Phase 3 doesn't have to do anything, because
* that effectively means that the default is NULL. The heap tuple access
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* routines always check for attnum > # of attributes in tuple, and return
* NULL if so, so without any modification of the tuple data we will get
* the effect of NULL values in the new column.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* An exception occurs when the new column is of a domain type: the domain
* might have a NOT NULL constraint, or a check constraint that indirectly
* rejects nulls. If there are any domain constraints then we construct
* an explicit NULL default value that will be passed through
* CoerceToDomain processing. (This is a tad inefficient, since it causes
* rewriting the table which we really don't have to do, but the present
* design of domain processing doesn't offer any simple way of checking
* the constraints more directly.)
Fix ALTER TABLE ADD COLUMN so that constraints of domain types are enforced properly when there is no explicit default value for the new column. Per report from Craig Perras.
2005-01-25 00:21:57 +01:00
*
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* Note: we use build_column_default, and not just the cooked default
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
* returned by AddRelationNewConstraints, so that the right thing happens
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* when a datatype's default applies.
Allow CREATE OR REPLACE VIEW to add columns to the _end_ of the view. Robert Haas
2008-12-07 00:22:46 +01:00
*
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
* We skip this step completely for views and foreign tables. For a view,
* we can only get here from CREATE OR REPLACE VIEW, which historically
* doesn't set up defaults, not even for domain-typed columns. And in any
* case we mustn't invoke Phase 3 on a view or foreign table, since they
* have no storage.
*/
if (relkind != RELKIND_VIEW && relkind != RELKIND_COMPOSITE_TYPE
&& relkind != RELKIND_FOREIGN_TABLE && attribute.attnum > 0)
Code review for CREATE OR REPLACE VIEW patch. Do things in a saner order to result in hopefully-less-confusing error messages when the new definition isn't compatible with the old; minor other cleanup.
2008-12-15 22:35:31 +01:00
{
Allow CREATE OR REPLACE VIEW to add columns to the _end_ of the view. Robert Haas
2008-12-07 00:22:46 +01:00
defval = (Expr *) build_column_default(rel, attribute.attnum);
Fix ALTER TABLE ADD COLUMN so that constraints of domain types are enforced properly when there is no explicit default value for the new column. Per report from Craig Perras.
2005-01-25 00:21:57 +01:00
Allow CREATE OR REPLACE VIEW to add columns to the _end_ of the view. Robert Haas
2008-12-07 00:22:46 +01:00
if (!defval && GetDomainConstraints(typeOid) != NIL)
{
Oid baseTypeId;
int32 baseTypeMod;
Pass collation to makeConst() instead of looking it up internally. 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.
2011-03-26 01:10:42 +01:00
Oid baseTypeColl;
Allow CREATE OR REPLACE VIEW to add columns to the _end_ of the view. Robert Haas
2008-12-07 00:22:46 +01:00
baseTypeMod = typmod;
baseTypeId = getBaseTypeAndTypmod(typeOid, &baseTypeMod);
Pass collation to makeConst() instead of looking it up internally. 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.
2011-03-26 01:10:42 +01:00
baseTypeColl = get_typcollation(baseTypeId);
defval = (Expr *) makeNullConst(baseTypeId, baseTypeMod, baseTypeColl);
Allow CREATE OR REPLACE VIEW to add columns to the _end_ of the view. Robert Haas
2008-12-07 00:22:46 +01:00
defval = (Expr *) coerce_to_target_type(NULL,
(Node *) defval,
baseTypeId,
typeOid,
typmod,
COERCION_ASSIGNMENT,
COERCE_IMPLICIT_CAST,
-1);
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
if (defval == NULL) /* should not happen */
Allow CREATE OR REPLACE VIEW to add columns to the _end_ of the view. Robert Haas
2008-12-07 00:22:46 +01:00
elog(ERROR, "failed to coerce base type to domain");
}
Fix ALTER TABLE ADD COLUMN so that constraints of domain types are enforced properly when there is no explicit default value for the new column. Per report from Craig Perras.
2005-01-25 00:21:57 +01:00
Allow CREATE OR REPLACE VIEW to add columns to the _end_ of the view. Robert Haas
2008-12-07 00:22:46 +01:00
if (defval)
{
NewColumnValue *newval;
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
Allow CREATE OR REPLACE VIEW to add columns to the _end_ of the view. Robert Haas
2008-12-07 00:22:46 +01:00
newval = (NewColumnValue *) palloc0(sizeof(NewColumnValue));
newval->attnum = attribute.attnum;
Add notion of a "transform function" that can simplify function calls. 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
2011-06-22 04:15:24 +02:00
newval->expr = expression_planner(defval);
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Allow CREATE OR REPLACE VIEW to add columns to the _end_ of the view. Robert Haas
2008-12-07 00:22:46 +01:00
tab->newvals = lappend(tab->newvals, newval);
Teach ALTER TABLE .. SET DATA TYPE to avoid some table rewrites. 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
2011-02-12 14:27:55 +01:00
tab->rewrite = true;
Allow CREATE OR REPLACE VIEW to add columns to the _end_ of the view. Robert Haas
2008-12-07 00:22:46 +01:00
}
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Allow CREATE OR REPLACE VIEW to add columns to the _end_ of the view. Robert Haas
2008-12-07 00:22:46 +01:00
/*
* If the new column is NOT NULL, tell Phase 3 it needs to test that.
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
* (Note we don't do this for an OID column. OID will be marked not
* null, but since it's filled specially, there's no need to test
* anything.)
Allow CREATE OR REPLACE VIEW to add columns to the _end_ of the view. Robert Haas
2008-12-07 00:22:46 +01:00
*/
tab->new_notnull |= colDef->is_not_null;
}
Fix ALTER TABLE ADD COLUMN ... PRIMARY KEY so that the new column is correctly checked to see if it's been initialized to all non-nulls. The implicit NOT NULL constraint was not being checked during the ALTER (in fact, not even if there was an explicit NOT NULL too), because ATExecAddColumn neglected to set the flag needed to make the test happen. This has been broken since the capability was first added, in 8.0. Brendan Jurd, per a report from Kaloyan Iliev.
2008-04-24 22:17:50 +02:00
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
/*
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* If we are adding an OID column, we have to tell Phase 3 to rewrite the
* table to fix that.
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
*/
if (isOid)
Teach ALTER TABLE .. SET DATA TYPE to avoid some table rewrites. 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
2011-02-12 14:27:55 +01:00
tab->rewrite = true;
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
Fix oversight in recent ALTER TABLE improvements. We now support ALTER TABLE tab ADD COLUMN col SERIAL, but we forgot to install the dependency between the column and the sequence, so the sequence would not go away if you dropped the table later.
2004-06-10 20:25:02 +02:00
* Add needed dependency entries for the new column.
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*/
Make a code-cleanup pass over the collations patch. 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().
2011-04-22 23:43:18 +02:00
add_column_datatype_dependency(myrelid, newattnum, attribute.atttypid);
add_column_collation_dependency(myrelid, newattnum, attribute.attcollation);
Rearrange "add column" logic to merge columns at exec time. 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.
2011-04-04 03:52:47 +02:00
/*
* Propagate to children as appropriate. Unlike most other ALTER
* routines, we have to do this one level of recursion at a time; we can't
* use find_all_inheritors to do it in one pass.
*/
children = find_inheritance_children(RelationGetRelid(rel), lockmode);
/*
* If we are told not to recurse, there had better not be any child
* tables; else the addition would put them out of step.
*/
if (children && !recurse)
ereport(ERROR,
(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
errmsg("column must be added to child tables too")));
/* Children should see column as singly inherited */
if (!recursing)
{
colDef = copyObject(colDef);
colDef->inhcount = 1;
colDef->is_local = false;
}
foreach(child, children)
{
Oid childrelid = lfirst_oid(child);
Relation childrel;
AlteredTableInfo *childtab;
/* find_inheritance_children already got lock */
childrel = heap_open(childrelid, NoLock);
CheckTableNotInUse(childrel, "ALTER TABLE");
/* Find or create work queue entry for this table */
childtab = ATGetQueueEntry(wqueue, childrel);
/* Recurse to child */
ATExecAddColumn(wqueue, childtab, childrel,
colDef, isOid, recurse, true, lockmode);
heap_close(childrel, NoLock);
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Be more clear when a new column name collides with a system column name. We now use the same error message for ALTER TABLE .. ADD COLUMN or ALTER TABLE .. RENAME COLUMN that we do for CREATE TABLE. The old message was accurate, but might be confusing to users not aware of our system columns. Vik Reykja, with some changes by me, and further proofreading by Tom Lane
2012-01-26 18:44:30 +01:00
/*
* If a new or renamed column will collide with the name of an existing
* column, error out.
*/
static void
check_for_column_name_collision(Relation rel, const char *colname)
{
HeapTuple attTuple;
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
int attnum;
Be more clear when a new column name collides with a system column name. We now use the same error message for ALTER TABLE .. ADD COLUMN or ALTER TABLE .. RENAME COLUMN that we do for CREATE TABLE. The old message was accurate, but might be confusing to users not aware of our system columns. Vik Reykja, with some changes by me, and further proofreading by Tom Lane
2012-01-26 18:44:30 +01:00
/*
* this test is deliberately not attisdropped-aware, since if one tries to
* add a column matching a dropped column name, it's gonna fail anyway.
*/
attTuple = SearchSysCache2(ATTNAME,
ObjectIdGetDatum(RelationGetRelid(rel)),
PointerGetDatum(colname));
if (!HeapTupleIsValid(attTuple))
return;
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
attnum = ((Form_pg_attribute) GETSTRUCT(attTuple))->attnum;
Be more clear when a new column name collides with a system column name. We now use the same error message for ALTER TABLE .. ADD COLUMN or ALTER TABLE .. RENAME COLUMN that we do for CREATE TABLE. The old message was accurate, but might be confusing to users not aware of our system columns. Vik Reykja, with some changes by me, and further proofreading by Tom Lane
2012-01-26 18:44:30 +01:00
ReleaseSysCache(attTuple);
/*
* We throw a different error message for conflicts with system column
* names, since they are normally not shown and the user might otherwise
* be confused about the reason for the conflict.
*/
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
if (attnum <= 0)
ereport(ERROR,
(errcode(ERRCODE_DUPLICATE_COLUMN),
errmsg("column name \"%s\" conflicts with a system column name",
colname)));
else
ereport(ERROR,
(errcode(ERRCODE_DUPLICATE_COLUMN),
errmsg("column \"%s\" of relation \"%s\" already exists",
colname, RelationGetRelationName(rel))));
Be more clear when a new column name collides with a system column name. We now use the same error message for ALTER TABLE .. ADD COLUMN or ALTER TABLE .. RENAME COLUMN that we do for CREATE TABLE. The old message was accurate, but might be confusing to users not aware of our system columns. Vik Reykja, with some changes by me, and further proofreading by Tom Lane
2012-01-26 18:44:30 +01:00
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* Install a column's dependency on its datatype.
*/
static void
Make a code-cleanup pass over the collations patch. 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().
2011-04-22 23:43:18 +02:00
add_column_datatype_dependency(Oid relid, int32 attnum, Oid typid)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
ObjectAddress myself,
referenced;
First phase of project to use fixed OIDs for all system catalogs and indexes. Extend the macros in include/catalog/*.h to carry the info about hand-assigned OIDs, and adjust the genbki script and bootstrap code to make the relations actually get those OIDs. Remove the small number of RelOid_pg_foo macros that we had in favor of a complete set named like the catname.h and indexing.h macros. Next phase will get rid of internal use of names for looking up catalogs and indexes; but this completes the changes forcing an initdb, so it looks like a good place to commit. Along the way, I made the shared relations (pg_database etc) not be 'bootstrap' relations any more, so as to reduce the number of hardwired entries and simplify changing those relations in future. I'm not sure whether they ever really needed to be handled as bootstrap relations, but it seems to work fine to not do so now.
2005-04-14 03:38:22 +02:00
myself.classId = RelationRelationId;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
myself.objectId = relid;
myself.objectSubId = attnum;
First phase of project to use fixed OIDs for all system catalogs and indexes. Extend the macros in include/catalog/*.h to carry the info about hand-assigned OIDs, and adjust the genbki script and bootstrap code to make the relations actually get those OIDs. Remove the small number of RelOid_pg_foo macros that we had in favor of a complete set named like the catname.h and indexing.h macros. Next phase will get rid of internal use of names for looking up catalogs and indexes; but this completes the changes forcing an initdb, so it looks like a good place to commit. Along the way, I made the shared relations (pg_database etc) not be 'bootstrap' relations any more, so as to reduce the number of hardwired entries and simplify changing those relations in future. I'm not sure whether they ever really needed to be handled as bootstrap relations, but it seems to work fine to not do so now.
2005-04-14 03:38:22 +02:00
referenced.classId = TypeRelationId;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
referenced.objectId = typid;
referenced.objectSubId = 0;
recordDependencyOn(&myself, &referenced, DEPENDENCY_NORMAL);
Make a code-cleanup pass over the collations patch. 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().
2011-04-22 23:43:18 +02:00
}
/*
* Install a column's dependency on its collation.
*/
static void
add_column_collation_dependency(Oid relid, int32 attnum, Oid collid)
{
ObjectAddress myself,
referenced;
DDL support for collations - 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
2011-02-12 14:54:13 +01:00
Make a code-cleanup pass over the collations patch. 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().
2011-04-22 23:43:18 +02:00
/* We know the default collation is pinned, so don't bother recording it */
if (OidIsValid(collid) && collid != DEFAULT_COLLATION_OID)
DDL support for collations - 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
2011-02-12 14:54:13 +01:00
{
Make a code-cleanup pass over the collations patch. 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().
2011-04-22 23:43:18 +02:00
myself.classId = RelationRelationId;
myself.objectId = relid;
myself.objectSubId = attnum;
DDL support for collations - 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
2011-02-12 14:54:13 +01:00
referenced.classId = CollationRelationId;
referenced.objectId = collid;
referenced.objectSubId = 0;
recordDependencyOn(&myself, &referenced, DEPENDENCY_NORMAL);
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
/*
* ALTER TABLE SET WITH OIDS
*
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* Basically this is an ADD COLUMN for the special OID column. We have
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
* to cons up a ColumnDef node because the ADD COLUMN code needs one.
*/
static void
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATPrepAddOids(List **wqueue, Relation rel, bool recurse, AlterTableCmd *cmd, LOCKMODE lockmode)
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
{
/* If we're recursing to a child table, the ColumnDef is already set up */
if (cmd->def == NULL)
{
ColumnDef *cdef = makeNode(ColumnDef);
cdef->colname = pstrdup("oid");
Remove collation information from TypeName, where it does not belong. 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.
2011-03-10 04:38:52 +01:00
cdef->typeName = makeTypeNameFromOid(OIDOID, -1);
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
cdef->inhcount = 0;
cdef->is_local = true;
cdef->is_not_null = true;
Code review for LIKE INCLUDING patch --- clean up some cosmetic and not so cosmetic stuff.
2009-10-13 02:53:08 +02:00
cdef->storage = 0;
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
cmd->def = (Node *) cdef;
}
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
ATPrepAddColumn(wqueue, rel, recurse, false, cmd, lockmode);
Rearrange "add column" logic to merge columns at exec time. 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.
2011-04-04 03:52:47 +02:00
if (recurse)
cmd->subtype = AT_AddOidsRecurse;
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* ALTER TABLE ALTER COLUMN DROP NOT NULL
*/
static void
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecDropNotNull(Relation rel, const char *colName, LOCKMODE lockmode)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
HeapTuple tuple;
AttrNumber attnum;
Relation attr_rel;
List *indexoidlist;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *indexoidscan;
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
/*
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* lookup the attribute
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
*/
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
attr_rel = heap_open(AttributeRelationId, RowExclusiveLock);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
tuple = SearchSysCacheCopyAttName(RelationGetRelid(rel), colName);
if (!HeapTupleIsValid(tuple))
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_COLUMN),
errmsg("column \"%s\" of relation \"%s\" does not exist",
colName, RelationGetRelationName(rel))));
attnum = ((Form_pg_attribute) GETSTRUCT(tuple))->attnum;
/* Prevent them from altering a system attribute */
if (attnum <= 0)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot alter system column \"%s\"",
colName)));
/*
* Check that the attribute is not in a primary key
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY. Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor choice of catalog state representation. The pg_index state for an index that's reached the final pre-drop stage was the same as the state for an index just created by CREATE INDEX CONCURRENTLY. This meant that the (necessary) change to make RelationGetIndexList ignore about-to-die indexes also made it ignore freshly-created indexes; which is catastrophic because the latter do need to be considered in HOT-safety decisions. Failure to do so leads to incorrect index entries and subsequently wrong results from queries depending on the concurrently-created index. To fix, add an additional boolean column "indislive" to pg_index, so that the freshly-created and about-to-die states can be distinguished. (This change obviously is only possible in HEAD. This patch will need to be back-patched, but in 9.2 we'll use a kluge consisting of overloading the formerly-impossible state of indisvalid = true and indisready = false.) In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index flag changes they make without exclusive lock on the index are made via heap_inplace_update() rather than a normal transactional update. The latter is not very safe because moving the pg_index tuple could result in concurrent SnapshotNow scans finding it twice or not at all, thus possibly resulting in index corruption. This is a pre-existing bug in CREATE INDEX CONCURRENTLY, which was copied into the DROP code. In addition, fix various places in the code that ought to check to make sure that the indexes they are manipulating are valid and/or ready as appropriate. These represent bugs that have existed since 8.2, since a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid index behind, and we ought not try to do anything that might fail with such an index. Also fix RelationReloadIndexInfo to ensure it copies all the pg_index columns that are allowed to change after initial creation. Previously we could have been left with stale values of some fields in an index relcache entry. It's not clear whether this actually had any user-visible consequences, but it's at least a bug waiting to happen. In addition, do some code and docs review for DROP INDEX CONCURRENTLY; some cosmetic code cleanup but mostly addition and revision of comments. This will need to be back-patched, but in a noticeably different form, so I'm committing it to HEAD before working on the back-patch. Problem reported by Amit Kapila, diagnosis by Pavan Deolassee, fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
*
* Note: we'll throw error even if the pkey index is not valid.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
/* Loop over all indexes on the relation */
indexoidlist = RelationGetIndexList(rel);
foreach(indexoidscan, indexoidlist)
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
{
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
Oid indexoid = lfirst_oid(indexoidscan);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
HeapTuple indexTuple;
Form_pg_index indexStruct;
int i;
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Wrap calls to SearchSysCache and related functions using macros. The purpose of this change is to eliminate the need for every caller of SearchSysCache, SearchSysCacheCopy, SearchSysCacheExists, GetSysCacheOid, and SearchSysCacheList to know the maximum number of allowable keys for a syscache entry (currently 4). This will make it far easier to increase the maximum number of keys in a future release should we choose to do so, and it makes the code shorter, too. Design and review by Tom Lane.
2010-02-14 19:42:19 +01:00
indexTuple = SearchSysCache1(INDEXRELID, ObjectIdGetDatum(indexoid));
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (!HeapTupleIsValid(indexTuple))
elog(ERROR, "cache lookup failed for index %u", indexoid);
indexStruct = (Form_pg_index) GETSTRUCT(indexTuple);
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* If the index is not a primary key, skip the check */
if (indexStruct->indisprimary)
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
{
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* Loop over each attribute in the primary key and see if it
* matches the to-be-altered attribute
*/
for (i = 0; i < indexStruct->indnatts; i++)
{
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
if (indexStruct->indkey.values[i] == attnum)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
ereport(ERROR,
(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
errmsg("column \"%s\" is in a primary key",
colName)));
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
ReleaseSysCache(indexTuple);
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
}
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
list_free(indexoidlist);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* Okay, actually perform the catalog change ... if needed
*/
if (((Form_pg_attribute) GETSTRUCT(tuple))->attnotnull)
{
((Form_pg_attribute) GETSTRUCT(tuple))->attnotnull = FALSE;
simple_heap_update(attr_rel, &tuple->t_self, tuple);
/* keep the system catalog indexes current */
CatalogUpdateIndexes(attr_rel, tuple);
}
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
InvokeObjectPostAlterHook(RelationRelationId,
RelationGetRelid(rel), attnum);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
heap_close(attr_rel, RowExclusiveLock);
}
/*
* ALTER TABLE ALTER COLUMN SET NOT NULL
*/
static void
ATExecSetNotNull(AlteredTableInfo *tab, Relation rel,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
const char *colName, LOCKMODE lockmode)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
HeapTuple tuple;
AttrNumber attnum;
Relation attr_rel;
/*
* lookup the attribute
*/
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
attr_rel = heap_open(AttributeRelationId, RowExclusiveLock);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
tuple = SearchSysCacheCopyAttName(RelationGetRelid(rel), colName);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
if (!HeapTupleIsValid(tuple))
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_COLUMN),
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
errmsg("column \"%s\" of relation \"%s\" does not exist",
colName, RelationGetRelationName(rel))));
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
attnum = ((Form_pg_attribute) GETSTRUCT(tuple))->attnum;
/* Prevent them from altering a system attribute */
if (attnum <= 0)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
Message editing: remove gratuitous variations in message wording, standardize terms, add some clarifications, fix some untranslatable attempts at dynamic message building.
2003-09-25 08:58:07 +02:00
errmsg("cannot alter system column \"%s\"",
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
colName)));
pgindent run.
2002-09-04 22:31:48 +02:00
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
/*
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* Okay, actually perform the catalog change ... if needed
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
*/
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
if (!((Form_pg_attribute) GETSTRUCT(tuple))->attnotnull)
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
{
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
((Form_pg_attribute) GETSTRUCT(tuple))->attnotnull = TRUE;
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
simple_heap_update(attr_rel, &tuple->t_self, tuple);
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* keep the system catalog indexes current */
CatalogUpdateIndexes(attr_rel, tuple);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
Fix ALTER TABLE to check pre-existing NOT NULL constraints when rewriting 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.
2006-07-11 00:10:39 +02:00
/* Tell Phase 3 it needs to test the constraint */
tab->new_notnull = true;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
InvokeObjectPostAlterHook(RelationRelationId,
RelationGetRelid(rel), attnum);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
heap_close(attr_rel, RowExclusiveLock);
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
}
Code for WITHOUT OIDS. On Wed, 2003-01-08 at 21:59, Christopher Kings-Lynne wrote: > I agree. I want to remove OIDs from heaps of our tables when we go to 7.3. > I'd rather not have to do it in the dump due to down time. Rod Taylor <rbt@rbt.ca>
2003-02-13 06:20:05 +01:00
/*
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* ALTER TABLE ALTER COLUMN SET/DROP DEFAULT
Code for WITHOUT OIDS. On Wed, 2003-01-08 at 21:59, Christopher Kings-Lynne wrote: > I agree. I want to remove OIDs from heaps of our tables when we go to 7.3. > I'd rather not have to do it in the dump due to down time. Rod Taylor <rbt@rbt.ca>
2003-02-13 06:20:05 +01:00
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static void
ATExecColumnDefault(Relation rel, const char *colName,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
Node *newDefault, LOCKMODE lockmode)
Code for WITHOUT OIDS. On Wed, 2003-01-08 at 21:59, Christopher Kings-Lynne wrote: > I agree. I want to remove OIDs from heaps of our tables when we go to 7.3. > I'd rather not have to do it in the dump due to down time. Rod Taylor <rbt@rbt.ca>
2003-02-13 06:20:05 +01:00
{
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
AttrNumber attnum;
Code for WITHOUT OIDS. On Wed, 2003-01-08 at 21:59, Christopher Kings-Lynne wrote: > I agree. I want to remove OIDs from heaps of our tables when we go to 7.3. > I'd rather not have to do it in the dump due to down time. Rod Taylor <rbt@rbt.ca>
2003-02-13 06:20:05 +01:00
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
/*
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* get the number of the attribute
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
attnum = get_attnum(RelationGetRelid(rel), colName);
if (attnum == InvalidAttrNumber)
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_COLUMN),
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
errmsg("column \"%s\" of relation \"%s\" does not exist",
colName, RelationGetRelationName(rel))));
Code for WITHOUT OIDS. On Wed, 2003-01-08 at 21:59, Christopher Kings-Lynne wrote: > I agree. I want to remove OIDs from heaps of our tables when we go to 7.3. > I'd rather not have to do it in the dump due to down time. Rod Taylor <rbt@rbt.ca>
2003-02-13 06:20:05 +01:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Prevent them from altering a system attribute */
if (attnum <= 0)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
errmsg("cannot alter system column \"%s\"",
colName)));
/*
* Remove any old default for the column. We use RESTRICT here for
* safety, but at present we do not expect anything to depend on the
* default.
Classify DROP operations by whether or not they are user-initiated. This doesn't do anything useful just yet, but is intended as supporting infrastructure for allowing sepgsql to sensibly check DROP permissions. KaiGai Kohei and Robert Haas
2012-01-26 15:24:54 +01:00
*
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* We treat removing the existing default as an internal operation when it
* is preparatory to adding a new default, but as a user-initiated
Classify DROP operations by whether or not they are user-initiated. This doesn't do anything useful just yet, but is intended as supporting infrastructure for allowing sepgsql to sensibly check DROP permissions. KaiGai Kohei and Robert Haas
2012-01-26 15:24:54 +01:00
* operation when the user asked for a drop.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
Classify DROP operations by whether or not they are user-initiated. This doesn't do anything useful just yet, but is intended as supporting infrastructure for allowing sepgsql to sensibly check DROP permissions. KaiGai Kohei and Robert Haas
2012-01-26 15:24:54 +01:00
RemoveAttrDefault(RelationGetRelid(rel), attnum, DROP_RESTRICT, false,
newDefault == NULL ? false : true);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (newDefault)
Code for WITHOUT OIDS. On Wed, 2003-01-08 at 21:59, Christopher Kings-Lynne wrote: > I agree. I want to remove OIDs from heaps of our tables when we go to 7.3. > I'd rather not have to do it in the dump due to down time. Rod Taylor <rbt@rbt.ca>
2003-02-13 06:20:05 +01:00
{
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* SET DEFAULT */
RawColumnDefault *rawEnt;
rawEnt = (RawColumnDefault *) palloc(sizeof(RawColumnDefault));
rawEnt->attnum = attnum;
rawEnt->raw_default = newDefault;
Code for WITHOUT OIDS. On Wed, 2003-01-08 at 21:59, Christopher Kings-Lynne wrote: > I agree. I want to remove OIDs from heaps of our tables when we go to 7.3. > I'd rather not have to do it in the dump due to down time. Rod Taylor <rbt@rbt.ca>
2003-02-13 06:20:05 +01:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* This function is intended for CREATE TABLE, so it processes a
* _list_ of defaults, but we just do one.
*/
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
AddRelationNewConstraints(rel, list_make1(rawEnt), NIL,
false, true, false);
Code for WITHOUT OIDS. On Wed, 2003-01-08 at 21:59, Christopher Kings-Lynne wrote: > I agree. I want to remove OIDs from heaps of our tables when we go to 7.3. > I'd rather not have to do it in the dump due to down time. Rod Taylor <rbt@rbt.ca>
2003-02-13 06:20:05 +01:00
}
}
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
/*
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* ALTER TABLE ALTER COLUMN SET STATISTICS
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static void
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATPrepSetStatistics(Relation rel, const char *colName, Node *newValue, LOCKMODE lockmode)
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
{
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
* We do our own permission checking because (a) we want to allow SET
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* STATISTICS on indexes (for expressional index columns), and (b) we want
* to allow SET STATISTICS on system catalogs without requiring
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
* allowSystemTableMods to be turned on.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
if (rel->rd_rel->relkind != RELKIND_RELATION &&
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
rel->rd_rel->relkind != RELKIND_MATVIEW &&
Allow statistics to be collected for foreign tables. ANALYZE now accepts foreign tables and allows the table's FDW to control how the sample rows are collected. (But only manual ANALYZEs will touch foreign tables, for the moment, since among other things it's not very clear how to handle remote permissions checks in an auto-analyze.) contrib/file_fdw is extended to support this. Etsuro Fujita, reviewed by Shigeru Hanada, some further tweaking by me.
2012-04-06 21:02:35 +02:00
rel->rd_rel->relkind != RELKIND_INDEX &&
rel->rd_rel->relkind != RELKIND_FOREIGN_TABLE)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
errmsg("\"%s\" is not a table, materialized view, index, or foreign table",
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
RelationGetRelationName(rel))));
ALTER TABLE DROP COLUMN works. Patch by Christopher Kings-Lynne, code review by Tom Lane. Remaining issues: functions that take or return tuple types are likely to break if one drops (or adds!) a column in the table defining the type. Need to think about what to do here. Along the way: some code review for recent COPY changes; mark system columns attnotnull = true where appropriate, per discussion a month ago.
2002-08-02 20:15:10 +02:00
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
/* Permissions checks */
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (!pg_class_ownercheck(RelationGetRelid(rel), GetUserId()))
Adjust 'permission denied' messages to be more useful and consistent.
2003-08-01 02:15:26 +02:00
aclcheck_error(ACLCHECK_NOT_OWNER, ACL_KIND_CLASS,
RelationGetRelationName(rel));
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
ALTER TABLE DROP COLUMN works. Patch by Christopher Kings-Lynne, code review by Tom Lane. Remaining issues: functions that take or return tuple types are likely to break if one drops (or adds!) a column in the table defining the type. Need to think about what to do here. Along the way: some code review for recent COPY changes; mark system columns attnotnull = true where appropriate, per discussion a month ago.
2002-08-02 20:15:10 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static void
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecSetStatistics(Relation rel, const char *colName, Node *newValue, LOCKMODE lockmode)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
int newtarget;
Relation attrelation;
HeapTuple tuple;
Form_pg_attribute attrtuple;
Assert(IsA(newValue, Integer));
newtarget = intVal(newValue);
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ALTER TABLE DROP COLUMN works. Patch by Christopher Kings-Lynne, code review by Tom Lane. Remaining issues: functions that take or return tuple types are likely to break if one drops (or adds!) a column in the table defining the type. Need to think about what to do here. Along the way: some code review for recent COPY changes; mark system columns attnotnull = true where appropriate, per discussion a month ago.
2002-08-02 20:15:10 +02:00
/*
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* Limit target to a sane range
ALTER TABLE DROP COLUMN works. Patch by Christopher Kings-Lynne, code review by Tom Lane. Remaining issues: functions that take or return tuple types are likely to break if one drops (or adds!) a column in the table defining the type. Need to think about what to do here. Along the way: some code review for recent COPY changes; mark system columns attnotnull = true where appropriate, per discussion a month ago.
2002-08-02 20:15:10 +02:00
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (newtarget < -1)
{
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("statistics target %d is too low",
newtarget)));
}
Increase the default value of default_statistics_target from 10 to 100, and its maximum value from 1000 to 10000. ALTER TABLE SET STATISTICS similarly now allows a value up to 10000. Per discussion.
2008-12-13 20:13:44 +01:00
else if (newtarget > 10000)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
Increase the default value of default_statistics_target from 10 to 100, and its maximum value from 1000 to 10000. ALTER TABLE SET STATISTICS similarly now allows a value up to 10000. Per discussion.
2008-12-13 20:13:44 +01:00
newtarget = 10000;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
ereport(WARNING,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("lowering statistics target to %d",
newtarget)));
}
ALTER TABLE DROP COLUMN works. Patch by Christopher Kings-Lynne, code review by Tom Lane. Remaining issues: functions that take or return tuple types are likely to break if one drops (or adds!) a column in the table defining the type. Need to think about what to do here. Along the way: some code review for recent COPY changes; mark system columns attnotnull = true where appropriate, per discussion a month ago.
2002-08-02 20:15:10 +02:00
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
attrelation = heap_open(AttributeRelationId, RowExclusiveLock);
Upgrade ALTER TABLE DROP COLUMN so that it can drop an OID column, and remove separate implementation of ALTER TABLE SET WITHOUT OIDS in favor of doing a regular DROP. Also, cause CREATE TABLE to account completely correctly for the inheritance status of the OID column. This fixes problems with dropping OID columns that have dependencies, as noted by Christopher Kings-Lynne, as well as making sure that you can't drop an OID column that was inherited from a parent.
2004-03-23 20:35:17 +01:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
tuple = SearchSysCacheCopyAttName(RelationGetRelid(rel), colName);
if (!HeapTupleIsValid(tuple))
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
(errcode(ERRCODE_UNDEFINED_COLUMN),
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
errmsg("column \"%s\" of relation \"%s\" does not exist",
colName, RelationGetRelationName(rel))));
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
attrtuple = (Form_pg_attribute) GETSTRUCT(tuple);
ALTER TABLE DROP COLUMN works. Patch by Christopher Kings-Lynne, code review by Tom Lane. Remaining issues: functions that take or return tuple types are likely to break if one drops (or adds!) a column in the table defining the type. Need to think about what to do here. Along the way: some code review for recent COPY changes; mark system columns attnotnull = true where appropriate, per discussion a month ago.
2002-08-02 20:15:10 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (attrtuple->attnum <= 0)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot alter system column \"%s\"",
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
colName)));
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
attrtuple->attstattarget = newtarget;
Upgrade ALTER TABLE DROP COLUMN so that it can drop an OID column, and remove separate implementation of ALTER TABLE SET WITHOUT OIDS in favor of doing a regular DROP. Also, cause CREATE TABLE to account completely correctly for the inheritance status of the OID column. This fixes problems with dropping OID columns that have dependencies, as noted by Christopher Kings-Lynne, as well as making sure that you can't drop an OID column that was inherited from a parent.
2004-03-23 20:35:17 +01:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
simple_heap_update(attrelation, &tuple->t_self, tuple);
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* keep system catalog indexes current */
CatalogUpdateIndexes(attrelation, tuple);
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
InvokeObjectPostAlterHook(RelationRelationId,
RelationGetRelid(rel),
attrtuple->attnum);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
heap_freetuple(tuple);
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
Add ALTER TABLE ... ALTER COLUMN ... SET STATISTICS DISTINCT Robert Haas
2009-08-03 00:14:53 +02:00
heap_close(attrelation, RowExclusiveLock);
}
static void
Replace ALTER TABLE ... SET STATISTICS DISTINCT with a more general mechanism. Attributes can now have options, just as relations and tablespaces do, and the reloptions code is used to parse, validate, and store them. For simplicity and because these options are not performance critical, we store them in a separate cache rather than the main relcache. Thanks to Alex Hunsaker for the review.
2010-01-22 17:40:19 +01:00
ATExecSetOptions(Relation rel, const char *colName, Node *options,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
bool isReset, LOCKMODE lockmode)
Add ALTER TABLE ... ALTER COLUMN ... SET STATISTICS DISTINCT Robert Haas
2009-08-03 00:14:53 +02:00
{
Relation attrelation;
Replace ALTER TABLE ... SET STATISTICS DISTINCT with a more general mechanism. Attributes can now have options, just as relations and tablespaces do, and the reloptions code is used to parse, validate, and store them. For simplicity and because these options are not performance critical, we store them in a separate cache rather than the main relcache. Thanks to Alex Hunsaker for the review.
2010-01-22 17:40:19 +01:00
HeapTuple tuple,
newtuple;
Add ALTER TABLE ... ALTER COLUMN ... SET STATISTICS DISTINCT Robert Haas
2009-08-03 00:14:53 +02:00
Form_pg_attribute attrtuple;
Replace ALTER TABLE ... SET STATISTICS DISTINCT with a more general mechanism. Attributes can now have options, just as relations and tablespaces do, and the reloptions code is used to parse, validate, and store them. For simplicity and because these options are not performance critical, we store them in a separate cache rather than the main relcache. Thanks to Alex Hunsaker for the review.
2010-01-22 17:40:19 +01:00
Datum datum,
newOptions;
bool isnull;
Datum repl_val[Natts_pg_attribute];
bool repl_null[Natts_pg_attribute];
bool repl_repl[Natts_pg_attribute];
Add ALTER TABLE ... ALTER COLUMN ... SET STATISTICS DISTINCT Robert Haas
2009-08-03 00:14:53 +02:00
attrelation = heap_open(AttributeRelationId, RowExclusiveLock);
Replace ALTER TABLE ... SET STATISTICS DISTINCT with a more general mechanism. Attributes can now have options, just as relations and tablespaces do, and the reloptions code is used to parse, validate, and store them. For simplicity and because these options are not performance critical, we store them in a separate cache rather than the main relcache. Thanks to Alex Hunsaker for the review.
2010-01-22 17:40:19 +01:00
tuple = SearchSysCacheAttName(RelationGetRelid(rel), colName);
Add ALTER TABLE ... ALTER COLUMN ... SET STATISTICS DISTINCT Robert Haas
2009-08-03 00:14:53 +02:00
if (!HeapTupleIsValid(tuple))
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_COLUMN),
errmsg("column \"%s\" of relation \"%s\" does not exist",
colName, RelationGetRelationName(rel))));
attrtuple = (Form_pg_attribute) GETSTRUCT(tuple);
if (attrtuple->attnum <= 0)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot alter system column \"%s\"",
colName)));
Replace ALTER TABLE ... SET STATISTICS DISTINCT with a more general mechanism. Attributes can now have options, just as relations and tablespaces do, and the reloptions code is used to parse, validate, and store them. For simplicity and because these options are not performance critical, we store them in a separate cache rather than the main relcache. Thanks to Alex Hunsaker for the review.
2010-01-22 17:40:19 +01:00
/* Generate new proposed attoptions (text array) */
Assert(IsA(options, List));
datum = SysCacheGetAttr(ATTNAME, tuple, Anum_pg_attribute_attoptions,
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
&isnull);
Replace ALTER TABLE ... SET STATISTICS DISTINCT with a more general mechanism. Attributes can now have options, just as relations and tablespaces do, and the reloptions code is used to parse, validate, and store them. For simplicity and because these options are not performance critical, we store them in a separate cache rather than the main relcache. Thanks to Alex Hunsaker for the review.
2010-01-22 17:40:19 +01:00
newOptions = transformRelOptions(isnull ? (Datum) 0 : datum,
(List *) options, NULL, NULL, false,
isReset);
/* Validate new options */
(void) attribute_reloptions(newOptions, true);
/* Build new tuple. */
memset(repl_null, false, sizeof(repl_null));
memset(repl_repl, false, sizeof(repl_repl));
if (newOptions != (Datum) 0)
repl_val[Anum_pg_attribute_attoptions - 1] = newOptions;
else
repl_null[Anum_pg_attribute_attoptions - 1] = true;
repl_repl[Anum_pg_attribute_attoptions - 1] = true;
newtuple = heap_modify_tuple(tuple, RelationGetDescr(attrelation),
repl_val, repl_null, repl_repl);
/* Update system catalog. */
simple_heap_update(attrelation, &newtuple->t_self, newtuple);
CatalogUpdateIndexes(attrelation, newtuple);
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
InvokeObjectPostAlterHook(RelationRelationId,
RelationGetRelid(rel),
attrtuple->attnum);
Replace ALTER TABLE ... SET STATISTICS DISTINCT with a more general mechanism. Attributes can now have options, just as relations and tablespaces do, and the reloptions code is used to parse, validate, and store them. For simplicity and because these options are not performance critical, we store them in a separate cache rather than the main relcache. Thanks to Alex Hunsaker for the review.
2010-01-22 17:40:19 +01:00
heap_freetuple(newtuple);
Add ALTER TABLE ... ALTER COLUMN ... SET STATISTICS DISTINCT Robert Haas
2009-08-03 00:14:53 +02:00
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
ReleaseSysCache(tuple);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
heap_close(attrelation, RowExclusiveLock);
}
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* ALTER TABLE ALTER COLUMN SET STORAGE
*/
static void
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecSetStorage(Relation rel, const char *colName, Node *newValue, LOCKMODE lockmode)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
char *storagemode;
char newstorage;
Relation attrelation;
HeapTuple tuple;
Form_pg_attribute attrtuple;
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Assert(IsA(newValue, String));
storagemode = strVal(newValue);
Solve the 'Turkish problem' with undesirable locale behavior for case conversion of basic ASCII letters. Remove all uses of strcasecmp and strncasecmp in favor of new functions pg_strcasecmp and pg_strncasecmp; remove most but not all direct uses of toupper and tolower in favor of pg_toupper and pg_tolower. These functions use the same notions of case folding already developed for identifier case conversion. I left the straight locale-based folding in place for situations where we are just manipulating user data and not trying to match it to built-in strings --- for example, the SQL upper() function is still locale dependent. Perhaps this will prove not to be what's wanted, but at the moment we can initdb and pass regression tests in Turkish locale.
2004-05-07 02:24:59 +02:00
if (pg_strcasecmp(storagemode, "plain") == 0)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
newstorage = 'p';
Solve the 'Turkish problem' with undesirable locale behavior for case conversion of basic ASCII letters. Remove all uses of strcasecmp and strncasecmp in favor of new functions pg_strcasecmp and pg_strncasecmp; remove most but not all direct uses of toupper and tolower in favor of pg_toupper and pg_tolower. These functions use the same notions of case folding already developed for identifier case conversion. I left the straight locale-based folding in place for situations where we are just manipulating user data and not trying to match it to built-in strings --- for example, the SQL upper() function is still locale dependent. Perhaps this will prove not to be what's wanted, but at the moment we can initdb and pass regression tests in Turkish locale.
2004-05-07 02:24:59 +02:00
else if (pg_strcasecmp(storagemode, "external") == 0)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
newstorage = 'e';
Solve the 'Turkish problem' with undesirable locale behavior for case conversion of basic ASCII letters. Remove all uses of strcasecmp and strncasecmp in favor of new functions pg_strcasecmp and pg_strncasecmp; remove most but not all direct uses of toupper and tolower in favor of pg_toupper and pg_tolower. These functions use the same notions of case folding already developed for identifier case conversion. I left the straight locale-based folding in place for situations where we are just manipulating user data and not trying to match it to built-in strings --- for example, the SQL upper() function is still locale dependent. Perhaps this will prove not to be what's wanted, but at the moment we can initdb and pass regression tests in Turkish locale.
2004-05-07 02:24:59 +02:00
else if (pg_strcasecmp(storagemode, "extended") == 0)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
newstorage = 'x';
Solve the 'Turkish problem' with undesirable locale behavior for case conversion of basic ASCII letters. Remove all uses of strcasecmp and strncasecmp in favor of new functions pg_strcasecmp and pg_strncasecmp; remove most but not all direct uses of toupper and tolower in favor of pg_toupper and pg_tolower. These functions use the same notions of case folding already developed for identifier case conversion. I left the straight locale-based folding in place for situations where we are just manipulating user data and not trying to match it to built-in strings --- for example, the SQL upper() function is still locale dependent. Perhaps this will prove not to be what's wanted, but at the moment we can initdb and pass regression tests in Turkish locale.
2004-05-07 02:24:59 +02:00
else if (pg_strcasecmp(storagemode, "main") == 0)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
newstorage = 'm';
else
{
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("invalid storage type \"%s\"",
storagemode)));
newstorage = 0; /* keep compiler quiet */
}
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
attrelation = heap_open(AttributeRelationId, RowExclusiveLock);
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
tuple = SearchSysCacheCopyAttName(RelationGetRelid(rel), colName);
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (!HeapTupleIsValid(tuple))
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_COLUMN),
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
errmsg("column \"%s\" of relation \"%s\" does not exist",
colName, RelationGetRelationName(rel))));
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
attrtuple = (Form_pg_attribute) GETSTRUCT(tuple);
Replace pg_attribute.attisinherited with attislocal and attinhcount columns, to allow more correct behavior in multiple-inheritance cases. Patch by Alvaro Herrera, review by Tom Lane.
2002-09-22 21:42:52 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (attrtuple->attnum <= 0)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot alter system column \"%s\"",
colName)));
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* safety check: do not allow toasted storage modes unless column datatype
* is TOAST-aware.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
if (newstorage == 'p' || TypeIsToastable(attrtuple->atttypid))
attrtuple->attstorage = newstorage;
else
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("column data type %s can only have storage PLAIN",
format_type_be(attrtuple->atttypid))));
simple_heap_update(attrelation, &tuple->t_self, tuple);
/* keep system catalog indexes current */
CatalogUpdateIndexes(attrelation, tuple);
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
InvokeObjectPostAlterHook(RelationRelationId,
RelationGetRelid(rel),
attrtuple->attnum);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
heap_freetuple(tuple);
heap_close(attrelation, RowExclusiveLock);
}
/*
* ALTER TABLE DROP COLUMN
*
* DROP COLUMN cannot use the normal ALTER TABLE recursion mechanism,
* because we have to decide at runtime whether to recurse or not depending
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
* on whether attinhcount goes to zero or not. (We can't check this in a
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* static pre-pass because it won't handle multiple inheritance situations
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
* correctly.)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
Add more checks against altering typed tables - Prohibit altering column type - Prohibit changing inheritance - Move checks from Exec to Prep phases in ALTER TABLE code backpatched to 9.0
2010-07-23 22:04:18 +02:00
static void
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
ATPrepDropColumn(List **wqueue, Relation rel, bool recurse, bool recursing,
AlterTableCmd *cmd, LOCKMODE lockmode)
Add more checks against altering typed tables - Prohibit altering column type - Prohibit changing inheritance - Move checks from Exec to Prep phases in ALTER TABLE code backpatched to 9.0
2010-07-23 22:04:18 +02:00
{
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
if (rel->rd_rel->reloftype && !recursing)
Add more checks against altering typed tables - Prohibit altering column type - Prohibit changing inheritance - Move checks from Exec to Prep phases in ALTER TABLE code backpatched to 9.0
2010-07-23 22:04:18 +02:00
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("cannot drop column from typed table")));
Add ALTER TYPE ... ADD/DROP/ALTER/RENAME ATTRIBUTE Like with tables, this also requires allowing the existence of composite types with zero attributes. reviewed by KaiGai Kohei
2010-09-26 13:41:03 +02:00
if (rel->rd_rel->relkind == RELKIND_COMPOSITE_TYPE)
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
ATTypedTableRecursion(wqueue, rel, cmd, lockmode);
Add ALTER TYPE ... ADD/DROP/ALTER/RENAME ATTRIBUTE Like with tables, this also requires allowing the existence of composite types with zero attributes. reviewed by KaiGai Kohei
2010-09-26 13:41:03 +02:00
Add more checks against altering typed tables - Prohibit altering column type - Prohibit changing inheritance - Move checks from Exec to Prep phases in ALTER TABLE code backpatched to 9.0
2010-07-23 22:04:18 +02:00
if (recurse)
cmd->subtype = AT_DropColumnRecurse;
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static void
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
ATExecDropColumn(List **wqueue, Relation rel, const char *colName,
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
DropBehavior behavior,
DROP IF EXISTS for columns and constraints. Andres Freund.
2009-07-20 04:42:28 +02:00
bool recurse, bool recursing,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
bool missing_ok, LOCKMODE lockmode)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
HeapTuple tuple;
Form_pg_attribute targetatt;
AttrNumber attnum;
List *children;
ObjectAddress object;
/* At top level, permission check was done in ATPrepCmd, else do it */
if (recursing)
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
ATSimplePermissions(rel, ATT_TABLE);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* get the number of the attribute
*/
tuple = SearchSysCacheAttName(RelationGetRelid(rel), colName);
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
if (!HeapTupleIsValid(tuple))
{
if (!missing_ok)
{
DROP IF EXISTS for columns and constraints. Andres Freund.
2009-07-20 04:42:28 +02:00
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_COLUMN),
errmsg("column \"%s\" of relation \"%s\" does not exist",
colName, RelationGetRelationName(rel))));
}
else
{
ereport(NOTICE,
(errmsg("column \"%s\" of relation \"%s\" does not exist, skipping",
colName, RelationGetRelationName(rel))));
return;
}
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
targetatt = (Form_pg_attribute) GETSTRUCT(tuple);
attnum = targetatt->attnum;
/* Can't drop a system attribute, except OID */
if (attnum <= 0 && attnum != ObjectIdAttributeNumber)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot drop system column \"%s\"",
colName)));
/* Don't drop inherited columns */
if (targetatt->attinhcount > 0 && !recursing)
ereport(ERROR,
(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
errmsg("cannot drop inherited column \"%s\"",
colName)));
ReleaseSysCache(tuple);
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
ALTER TABLE DROP COLUMN works. Patch by Christopher Kings-Lynne, code review by Tom Lane. Remaining issues: functions that take or return tuple types are likely to break if one drops (or adds!) a column in the table defining the type. Need to think about what to do here. Along the way: some code review for recent COPY changes; mark system columns attnotnull = true where appropriate, per discussion a month ago.
2002-08-02 20:15:10 +02:00
/*
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* Propagate to children as appropriate. Unlike most other ALTER
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* routines, we have to do this one level of recursion at a time; we can't
* use find_all_inheritors to do it in one pass.
ALTER TABLE DROP COLUMN works. Patch by Christopher Kings-Lynne, code review by Tom Lane. Remaining issues: functions that take or return tuple types are likely to break if one drops (or adds!) a column in the table defining the type. Need to think about what to do here. Along the way: some code review for recent COPY changes; mark system columns attnotnull = true where appropriate, per discussion a month ago.
2002-08-02 20:15:10 +02:00
*/
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
children = find_inheritance_children(RelationGetRelid(rel), lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (children)
ALTER TABLE DROP COLUMN works. Patch by Christopher Kings-Lynne, code review by Tom Lane. Remaining issues: functions that take or return tuple types are likely to break if one drops (or adds!) a column in the table defining the type. Need to think about what to do here. Along the way: some code review for recent COPY changes; mark system columns attnotnull = true where appropriate, per discussion a month ago.
2002-08-02 20:15:10 +02:00
{
Replace pg_attribute.attisinherited with attislocal and attinhcount columns, to allow more correct behavior in multiple-inheritance cases. Patch by Alvaro Herrera, review by Tom Lane.
2002-09-22 21:42:52 +02:00
Relation attr_rel;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *child;
ALTER TABLE DROP COLUMN works. Patch by Christopher Kings-Lynne, code review by Tom Lane. Remaining issues: functions that take or return tuple types are likely to break if one drops (or adds!) a column in the table defining the type. Need to think about what to do here. Along the way: some code review for recent COPY changes; mark system columns attnotnull = true where appropriate, per discussion a month ago.
2002-08-02 20:15:10 +02:00
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
attr_rel = heap_open(AttributeRelationId, RowExclusiveLock);
ALTER TABLE DROP COLUMN works. Patch by Christopher Kings-Lynne, code review by Tom Lane. Remaining issues: functions that take or return tuple types are likely to break if one drops (or adds!) a column in the table defining the type. Need to think about what to do here. Along the way: some code review for recent COPY changes; mark system columns attnotnull = true where appropriate, per discussion a month ago.
2002-08-02 20:15:10 +02:00
foreach(child, children)
{
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
Oid childrelid = lfirst_oid(child);
Replace pg_attribute.attisinherited with attislocal and attinhcount columns, to allow more correct behavior in multiple-inheritance cases. Patch by Alvaro Herrera, review by Tom Lane.
2002-09-22 21:42:52 +02:00
Relation childrel;
Form_pg_attribute childatt;
ALTER TABLE DROP COLUMN works. Patch by Christopher Kings-Lynne, code review by Tom Lane. Remaining issues: functions that take or return tuple types are likely to break if one drops (or adds!) a column in the table defining the type. Need to think about what to do here. Along the way: some code review for recent COPY changes; mark system columns attnotnull = true where appropriate, per discussion a month ago.
2002-08-02 20:15:10 +02:00
Modify find_inheritance_children() and find_all_inheritors() to add the ability to lock relations as they scan pg_inherits, and to ignore any relations that have disappeared by the time we get lock on them. This makes uses of these functions safe against concurrent DROP operations on child tables: we will effectively ignore any just-dropped child, rather than possibly throwing an error as in recent bug report from Thomas Johansson (and similar past complaints). The behavior should not change otherwise, since the code was acquiring those same locks anyway, just a little bit later. An exception is LockTableCommand(), which is still behaving unsafely; but that seems to require some more discussion before we change it.
2009-05-12 05:11:02 +02:00
/* find_inheritance_children already got lock */
childrel = heap_open(childrelid, NoLock);
Add checks to TRUNCATE, CLUSTER, and REINDEX to prevent performing these operations when the current transaction has any open references to the target relation or index (implying it has an active query using the relation). The need for this was previously recognized in connection with ALTER TABLE, but anything that summarily eliminates tuples or moves them around would confuse an active scan. While this patch does not in itself fix bug #3883 (the deadlock would happen before the new check fires), it will discourage people from attempting the sequence of operations that creates a deadlock risk, so it's at least a partial response to that problem. In passing, add a previously-missing check to REINDEX to prevent trying to reindex another backend's temp table. This isn't a security problem since only a superuser would get past the schema permission checks, but if we are testing for this in other utility commands then surely REINDEX should too.
2008-01-30 20:46:48 +01:00
CheckTableNotInUse(childrel, "ALTER TABLE");
Replace pg_attribute.attisinherited with attislocal and attinhcount columns, to allow more correct behavior in multiple-inheritance cases. Patch by Alvaro Herrera, review by Tom Lane.
2002-09-22 21:42:52 +02:00
tuple = SearchSysCacheCopyAttName(childrelid, colName);
if (!HeapTupleIsValid(tuple)) /* shouldn't happen */
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
elog(ERROR, "cache lookup failed for attribute \"%s\" of relation %u",
colName, childrelid);
Replace pg_attribute.attisinherited with attislocal and attinhcount columns, to allow more correct behavior in multiple-inheritance cases. Patch by Alvaro Herrera, review by Tom Lane.
2002-09-22 21:42:52 +02:00
childatt = (Form_pg_attribute) GETSTRUCT(tuple);
pgindent run.
2003-08-04 02:43:34 +02:00
if (childatt->attinhcount <= 0) /* shouldn't happen */
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
elog(ERROR, "relation %u has non-inherited attribute \"%s\"",
Replace pg_attribute.attisinherited with attislocal and attinhcount columns, to allow more correct behavior in multiple-inheritance cases. Patch by Alvaro Herrera, review by Tom Lane.
2002-09-22 21:42:52 +02:00
childrelid, colName);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (recurse)
Replace pg_attribute.attisinherited with attislocal and attinhcount columns, to allow more correct behavior in multiple-inheritance cases. Patch by Alvaro Herrera, review by Tom Lane.
2002-09-22 21:42:52 +02:00
{
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* If the child column has other definition sources, just
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* decrement its inheritance count; if not, recurse to delete
* it.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
if (childatt->attinhcount == 1 && !childatt->attislocal)
{
/* Time to delete this child column, too */
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
ATExecDropColumn(wqueue, childrel, colName,
DROP IF EXISTS for columns and constraints. Andres Freund.
2009-07-20 04:42:28 +02:00
behavior, true, true,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
false, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
else
{
/* Child column must survive my deletion */
childatt->attinhcount--;
simple_heap_update(attr_rel, &tuple->t_self, tuple);
/* keep the system catalog indexes current */
CatalogUpdateIndexes(attr_rel, tuple);
/* Make update visible */
CommandCounterIncrement();
}
Replace pg_attribute.attisinherited with attislocal and attinhcount columns, to allow more correct behavior in multiple-inheritance cases. Patch by Alvaro Herrera, review by Tom Lane.
2002-09-22 21:42:52 +02:00
}
else
{
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* If we were told to drop ONLY in this table (no recursion),
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
* we need to mark the inheritors' attributes as locally
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* defined rather than inherited.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
Replace pg_attribute.attisinherited with attislocal and attinhcount columns, to allow more correct behavior in multiple-inheritance cases. Patch by Alvaro Herrera, review by Tom Lane.
2002-09-22 21:42:52 +02:00
childatt->attinhcount--;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
childatt->attislocal = true;
Replace pg_attribute.attisinherited with attislocal and attinhcount columns, to allow more correct behavior in multiple-inheritance cases. Patch by Alvaro Herrera, review by Tom Lane.
2002-09-22 21:42:52 +02:00
simple_heap_update(attr_rel, &tuple->t_self, tuple);
/* keep the system catalog indexes current */
CatalogUpdateIndexes(attr_rel, tuple);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Make update visible */
CommandCounterIncrement();
Replace pg_attribute.attisinherited with attislocal and attinhcount columns, to allow more correct behavior in multiple-inheritance cases. Patch by Alvaro Herrera, review by Tom Lane.
2002-09-22 21:42:52 +02:00
}
heap_freetuple(tuple);
heap_close(childrel, NoLock);
ALTER TABLE DROP COLUMN works. Patch by Christopher Kings-Lynne, code review by Tom Lane. Remaining issues: functions that take or return tuple types are likely to break if one drops (or adds!) a column in the table defining the type. Need to think about what to do here. Along the way: some code review for recent COPY changes; mark system columns attnotnull = true where appropriate, per discussion a month ago.
2002-08-02 20:15:10 +02:00
}
Replace pg_attribute.attisinherited with attislocal and attinhcount columns, to allow more correct behavior in multiple-inheritance cases. Patch by Alvaro Herrera, review by Tom Lane.
2002-09-22 21:42:52 +02:00
heap_close(attr_rel, RowExclusiveLock);
ALTER TABLE DROP COLUMN works. Patch by Christopher Kings-Lynne, code review by Tom Lane. Remaining issues: functions that take or return tuple types are likely to break if one drops (or adds!) a column in the table defining the type. Need to think about what to do here. Along the way: some code review for recent COPY changes; mark system columns attnotnull = true where appropriate, per discussion a month ago.
2002-08-02 20:15:10 +02:00
}
/*
Upgrade ALTER TABLE DROP COLUMN so that it can drop an OID column, and remove separate implementation of ALTER TABLE SET WITHOUT OIDS in favor of doing a regular DROP. Also, cause CREATE TABLE to account completely correctly for the inheritance status of the OID column. This fixes problems with dropping OID columns that have dependencies, as noted by Christopher Kings-Lynne, as well as making sure that you can't drop an OID column that was inherited from a parent.
2004-03-23 20:35:17 +01:00
* Perform the actual column deletion
ALTER TABLE DROP COLUMN works. Patch by Christopher Kings-Lynne, code review by Tom Lane. Remaining issues: functions that take or return tuple types are likely to break if one drops (or adds!) a column in the table defining the type. Need to think about what to do here. Along the way: some code review for recent COPY changes; mark system columns attnotnull = true where appropriate, per discussion a month ago.
2002-08-02 20:15:10 +02:00
*/
First phase of project to use fixed OIDs for all system catalogs and indexes. Extend the macros in include/catalog/*.h to carry the info about hand-assigned OIDs, and adjust the genbki script and bootstrap code to make the relations actually get those OIDs. Remove the small number of RelOid_pg_foo macros that we had in favor of a complete set named like the catname.h and indexing.h macros. Next phase will get rid of internal use of names for looking up catalogs and indexes; but this completes the changes forcing an initdb, so it looks like a good place to commit. Along the way, I made the shared relations (pg_database etc) not be 'bootstrap' relations any more, so as to reduce the number of hardwired entries and simplify changing those relations in future. I'm not sure whether they ever really needed to be handled as bootstrap relations, but it seems to work fine to not do so now.
2005-04-14 03:38:22 +02:00
object.classId = RelationRelationId;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
object.objectId = RelationGetRelid(rel);
ALTER TABLE DROP COLUMN works. Patch by Christopher Kings-Lynne, code review by Tom Lane. Remaining issues: functions that take or return tuple types are likely to break if one drops (or adds!) a column in the table defining the type. Need to think about what to do here. Along the way: some code review for recent COPY changes; mark system columns attnotnull = true where appropriate, per discussion a month ago.
2002-08-02 20:15:10 +02:00
object.objectSubId = attnum;
Classify DROP operations by whether or not they are user-initiated. This doesn't do anything useful just yet, but is intended as supporting infrastructure for allowing sepgsql to sensibly check DROP permissions. KaiGai Kohei and Robert Haas
2012-01-26 15:24:54 +01:00
performDeletion(&object, behavior, 0);
ALTER TABLE DROP COLUMN works. Patch by Christopher Kings-Lynne, code review by Tom Lane. Remaining issues: functions that take or return tuple types are likely to break if one drops (or adds!) a column in the table defining the type. Need to think about what to do here. Along the way: some code review for recent COPY changes; mark system columns attnotnull = true where appropriate, per discussion a month ago.
2002-08-02 20:15:10 +02:00
Upgrade ALTER TABLE DROP COLUMN so that it can drop an OID column, and remove separate implementation of ALTER TABLE SET WITHOUT OIDS in favor of doing a regular DROP. Also, cause CREATE TABLE to account completely correctly for the inheritance status of the OID column. This fixes problems with dropping OID columns that have dependencies, as noted by Christopher Kings-Lynne, as well as making sure that you can't drop an OID column that was inherited from a parent.
2004-03-23 20:35:17 +01:00
/*
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* If we dropped the OID column, must adjust pg_class.relhasoids and tell
Add a comment explaining why we force physical removal of OIDs. Noah Misch, slightly revised.
2011-01-26 12:42:51 +01:00
* Phase 3 to physically get rid of the column. We formerly left the
* column in place physically, but this caused subtle problems. See
* http://archives.postgresql.org/pgsql-hackers/2009-02/msg00363.php
Upgrade ALTER TABLE DROP COLUMN so that it can drop an OID column, and remove separate implementation of ALTER TABLE SET WITHOUT OIDS in favor of doing a regular DROP. Also, cause CREATE TABLE to account completely correctly for the inheritance status of the OID column. This fixes problems with dropping OID columns that have dependencies, as noted by Christopher Kings-Lynne, as well as making sure that you can't drop an OID column that was inherited from a parent.
2004-03-23 20:35:17 +01:00
*/
if (attnum == ObjectIdAttributeNumber)
{
Relation class_rel;
Form_pg_class tuple_class;
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
AlteredTableInfo *tab;
Upgrade ALTER TABLE DROP COLUMN so that it can drop an OID column, and remove separate implementation of ALTER TABLE SET WITHOUT OIDS in favor of doing a regular DROP. Also, cause CREATE TABLE to account completely correctly for the inheritance status of the OID column. This fixes problems with dropping OID columns that have dependencies, as noted by Christopher Kings-Lynne, as well as making sure that you can't drop an OID column that was inherited from a parent.
2004-03-23 20:35:17 +01:00
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
class_rel = heap_open(RelationRelationId, RowExclusiveLock);
Upgrade ALTER TABLE DROP COLUMN so that it can drop an OID column, and remove separate implementation of ALTER TABLE SET WITHOUT OIDS in favor of doing a regular DROP. Also, cause CREATE TABLE to account completely correctly for the inheritance status of the OID column. This fixes problems with dropping OID columns that have dependencies, as noted by Christopher Kings-Lynne, as well as making sure that you can't drop an OID column that was inherited from a parent.
2004-03-23 20:35:17 +01:00
Wrap calls to SearchSysCache and related functions using macros. The purpose of this change is to eliminate the need for every caller of SearchSysCache, SearchSysCacheCopy, SearchSysCacheExists, GetSysCacheOid, and SearchSysCacheList to know the maximum number of allowable keys for a syscache entry (currently 4). This will make it far easier to increase the maximum number of keys in a future release should we choose to do so, and it makes the code shorter, too. Design and review by Tom Lane.
2010-02-14 19:42:19 +01:00
tuple = SearchSysCacheCopy1(RELOID,
ObjectIdGetDatum(RelationGetRelid(rel)));
Upgrade ALTER TABLE DROP COLUMN so that it can drop an OID column, and remove separate implementation of ALTER TABLE SET WITHOUT OIDS in favor of doing a regular DROP. Also, cause CREATE TABLE to account completely correctly for the inheritance status of the OID column. This fixes problems with dropping OID columns that have dependencies, as noted by Christopher Kings-Lynne, as well as making sure that you can't drop an OID column that was inherited from a parent.
2004-03-23 20:35:17 +01:00
if (!HeapTupleIsValid(tuple))
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
elog(ERROR, "cache lookup failed for relation %u",
RelationGetRelid(rel));
Upgrade ALTER TABLE DROP COLUMN so that it can drop an OID column, and remove separate implementation of ALTER TABLE SET WITHOUT OIDS in favor of doing a regular DROP. Also, cause CREATE TABLE to account completely correctly for the inheritance status of the OID column. This fixes problems with dropping OID columns that have dependencies, as noted by Christopher Kings-Lynne, as well as making sure that you can't drop an OID column that was inherited from a parent.
2004-03-23 20:35:17 +01:00
tuple_class = (Form_pg_class) GETSTRUCT(tuple);
tuple_class->relhasoids = false;
simple_heap_update(class_rel, &tuple->t_self, tuple);
/* Keep the catalog indexes up to date */
CatalogUpdateIndexes(class_rel, tuple);
heap_close(class_rel, RowExclusiveLock);
Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically get rid of the OID column. This eliminates the problem discovered by Heikki back in November that 8.4's suppression of "unnecessary" junk filtering in INSERT/SELECT could lead to an Assert failure, or storing of oids into a table that shouldn't have them if Asserts are off. While that particular problem could have been solved in other ways, it seems likely to be just a forerunner of things to come if we continue to allow tables to contain rows that disagree with the pg_class.relhasoids setting. It's better to make this operation slow than to sacrifice performance or risk bugs in more common code paths. Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids. This was a bit more controversial, but in view of the very small amount of extra code needed given the current ALTER TABLE infrastructure, it seems best to eliminate the asymmetry in features.
2009-02-11 22:11:16 +01:00
/* Find or create work queue entry for this table */
tab = ATGetQueueEntry(wqueue, rel);
/* Tell Phase 3 to physically remove the OID column */
Teach ALTER TABLE .. SET DATA TYPE to avoid some table rewrites. 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
2011-02-12 14:27:55 +01:00
tab->rewrite = true;
Upgrade ALTER TABLE DROP COLUMN so that it can drop an OID column, and remove separate implementation of ALTER TABLE SET WITHOUT OIDS in favor of doing a regular DROP. Also, cause CREATE TABLE to account completely correctly for the inheritance status of the OID column. This fixes problems with dropping OID columns that have dependencies, as noted by Christopher Kings-Lynne, as well as making sure that you can't drop an OID column that was inherited from a parent.
2004-03-23 20:35:17 +01:00
}
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* ALTER TABLE ADD INDEX
*
Separate parse-analysis for utility commands out of parser/analyze.c (which now deals only in optimizable statements), and put that code into a new file parser/parse_utilcmd.c. This helps clarify and enforce the design rule that utility statements shouldn't be processed during the regular parse analysis phase; all interpretation of their meaning should happen after they are given to ProcessUtility to execute. (We need this because we don't retain any locks for a utility statement that's in a plan cache, nor have any way to detect that it's stale.) We are also able to simplify the API for parse_analyze() and related routines, because they will now always return exactly one Query structure. In passing, fix bug #3403 concerning trying to add a serial column to an existing temp table (this is largely Heikki's work, but we needed all that restructuring to make it safe).
2007-06-24 00:12:52 +02:00
* There is no such command in the grammar, but parse_utilcmd.c converts
* UNIQUE and PRIMARY KEY constraints into AT_AddIndex subcommands. This lets
* us schedule creation of the index at the appropriate time during ALTER.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
static void
ATExecAddIndex(AlteredTableInfo *tab, Relation rel,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
IndexStmt *stmt, bool is_rebuild, LOCKMODE lockmode)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
bool check_rights;
bool skip_build;
bool quiet;
Avoid index rebuild for no-rewrite ALTER TABLE .. ALTER TYPE. Noah Misch. Review and minor cosmetic changes by me.
2011-07-18 17:02:48 +02:00
Oid new_index;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Assert(IsA(stmt, IndexStmt));
Avoid pre-determining index names during CREATE TABLE LIKE parsing. Formerly, when trying to copy both indexes and comments, CREATE TABLE LIKE had to pre-assign names to indexes that had comments, because it made up an explicit CommentStmt command to apply the comment and so it had to know the name for the index. This creates bad interactions with other indexes, as shown in bug #6734 from Daniele Varrazzo: the preassignment logic couldn't take any other indexes into account so it could choose a conflicting name. To fix, add a field to IndexStmt that allows it to carry a comment to be assigned to the new index. (This isn't a user-exposed feature of CREATE INDEX, only an internal option.) Now we don't need preassignment of index names in any situation. I also took the opportunity to refactor DefineIndex to accept the IndexStmt as such, rather than passing all its fields individually in a mile-long parameter list. Back-patch to 9.2, but no further, because it seems too dangerous to change IndexStmt or DefineIndex's API in released branches. The bug exists back to 9.0 where CREATE TABLE LIKE grew the ability to copy comments, but given the lack of prior complaints we'll just let it go unfixed before 9.2.
2012-07-16 19:25:18 +02:00
Assert(!stmt->concurrent);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* suppress schema rights check when rebuilding existing index */
check_rights = !is_rebuild;
Avoid index rebuild for no-rewrite ALTER TABLE .. ALTER TYPE. Noah Misch. Review and minor cosmetic changes by me.
2011-07-18 17:02:48 +02:00
/* skip index build if phase 3 will do it or we're reusing an old one */
skip_build = tab->rewrite || OidIsValid(stmt->oldNode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* suppress notices when rebuilding existing index */
quiet = is_rebuild;
Separate parse-analysis for utility commands out of parser/analyze.c (which now deals only in optimizable statements), and put that code into a new file parser/parse_utilcmd.c. This helps clarify and enforce the design rule that utility statements shouldn't be processed during the regular parse analysis phase; all interpretation of their meaning should happen after they are given to ProcessUtility to execute. (We need this because we don't retain any locks for a utility statement that's in a plan cache, nor have any way to detect that it's stale.) We are also able to simplify the API for parse_analyze() and related routines, because they will now always return exactly one Query structure. In passing, fix bug #3403 concerning trying to add a serial column to an existing temp table (this is largely Heikki's work, but we needed all that restructuring to make it safe).
2007-06-24 00:12:52 +02:00
/* The IndexStmt has already been through transformIndexStmt */
First phase of plan-invalidation project: create a plan cache management 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.
2007-03-13 01:33:44 +01:00
Avoid pre-determining index names during CREATE TABLE LIKE parsing. Formerly, when trying to copy both indexes and comments, CREATE TABLE LIKE had to pre-assign names to indexes that had comments, because it made up an explicit CommentStmt command to apply the comment and so it had to know the name for the index. This creates bad interactions with other indexes, as shown in bug #6734 from Daniele Varrazzo: the preassignment logic couldn't take any other indexes into account so it could choose a conflicting name. To fix, add a field to IndexStmt that allows it to carry a comment to be assigned to the new index. (This isn't a user-exposed feature of CREATE INDEX, only an internal option.) Now we don't need preassignment of index names in any situation. I also took the opportunity to refactor DefineIndex to accept the IndexStmt as such, rather than passing all its fields individually in a mile-long parameter list. Back-patch to 9.2, but no further, because it seems too dangerous to change IndexStmt or DefineIndex's API in released branches. The bug exists back to 9.0 where CREATE TABLE LIKE grew the ability to copy comments, but given the lack of prior complaints we'll just let it go unfixed before 9.2.
2012-07-16 19:25:18 +02:00
new_index = DefineIndex(stmt,
Avoid index rebuild for no-rewrite ALTER TABLE .. ALTER TYPE. Noah Misch. Review and minor cosmetic changes by me.
2011-07-18 17:02:48 +02:00
InvalidOid, /* no predefined OID */
true, /* is_alter_table */
check_rights,
skip_build,
Avoid pre-determining index names during CREATE TABLE LIKE parsing. Formerly, when trying to copy both indexes and comments, CREATE TABLE LIKE had to pre-assign names to indexes that had comments, because it made up an explicit CommentStmt command to apply the comment and so it had to know the name for the index. This creates bad interactions with other indexes, as shown in bug #6734 from Daniele Varrazzo: the preassignment logic couldn't take any other indexes into account so it could choose a conflicting name. To fix, add a field to IndexStmt that allows it to carry a comment to be assigned to the new index. (This isn't a user-exposed feature of CREATE INDEX, only an internal option.) Now we don't need preassignment of index names in any situation. I also took the opportunity to refactor DefineIndex to accept the IndexStmt as such, rather than passing all its fields individually in a mile-long parameter list. Back-patch to 9.2, but no further, because it seems too dangerous to change IndexStmt or DefineIndex's API in released branches. The bug exists back to 9.0 where CREATE TABLE LIKE grew the ability to copy comments, but given the lack of prior complaints we'll just let it go unfixed before 9.2.
2012-07-16 19:25:18 +02:00
quiet);
Avoid index rebuild for no-rewrite ALTER TABLE .. ALTER TYPE. Noah Misch. Review and minor cosmetic changes by me.
2011-07-18 17:02:48 +02:00
/*
* If TryReuseIndex() stashed a relfilenode for us, we used it for the new
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* index instead of building from scratch. The DROP of the old edition of
Avoid index rebuild for no-rewrite ALTER TABLE .. ALTER TYPE. Noah Misch. Review and minor cosmetic changes by me.
2011-07-18 17:02:48 +02:00
* this index will have scheduled the storage for deletion at commit, so
* cancel that pending deletion.
*/
if (OidIsValid(stmt->oldNode))
{
Relation irel = index_open(new_index, NoLock);
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
Avoid index rebuild for no-rewrite ALTER TABLE .. ALTER TYPE. Noah Misch. Review and minor cosmetic changes by me.
2011-07-18 17:02:48 +02:00
RelationPreserveStorage(irel->rd_node, true);
index_close(irel, NoLock);
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Implement ALTER TABLE ADD UNIQUE/PRIMARY KEY USING INDEX. This feature allows a unique or pkey constraint to be created using an already-existing unique index. While the constraint isn't very functionally different from the bare index, it's nice to be able to do that for documentation purposes. The main advantage over just issuing a plain ALTER TABLE ADD UNIQUE/PRIMARY KEY is that the index can be created with CREATE INDEX CONCURRENTLY, so that there is not a long interval where the table is locked against updates. On the way, refactor some of the code in DefineIndex() and index_create() so that we don't have to pass through those functions in order to create the index constraint's catalog entries. Also, in parse_utilcmd.c, pass around the ParseState pointer in struct CreateStmtContext to save on notation, and add error location pointers to some error reports that didn't have one before. Gurjeet Singh, reviewed by Steve Singer and Tom Lane
2011-01-25 21:42:03 +01:00
/*
* ALTER TABLE ADD CONSTRAINT USING INDEX
*/
static void
ATExecAddIndexConstraint(AlteredTableInfo *tab, Relation rel,
IndexStmt *stmt, LOCKMODE lockmode)
{
Oid index_oid = stmt->indexOid;
Relation indexRel;
char *indexName;
IndexInfo *indexInfo;
char *constraintName;
char constraintType;
Assert(IsA(stmt, IndexStmt));
Assert(OidIsValid(index_oid));
Assert(stmt->isconstraint);
indexRel = index_open(index_oid, AccessShareLock);
indexName = pstrdup(RelationGetRelationName(indexRel));
indexInfo = BuildIndexInfo(indexRel);
/* this should have been checked at parse time */
if (!indexInfo->ii_Unique)
elog(ERROR, "index \"%s\" is not unique", indexName);
/*
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
* Determine name to assign to constraint. We require a constraint to
Implement ALTER TABLE ADD UNIQUE/PRIMARY KEY USING INDEX. This feature allows a unique or pkey constraint to be created using an already-existing unique index. While the constraint isn't very functionally different from the bare index, it's nice to be able to do that for documentation purposes. The main advantage over just issuing a plain ALTER TABLE ADD UNIQUE/PRIMARY KEY is that the index can be created with CREATE INDEX CONCURRENTLY, so that there is not a long interval where the table is locked against updates. On the way, refactor some of the code in DefineIndex() and index_create() so that we don't have to pass through those functions in order to create the index constraint's catalog entries. Also, in parse_utilcmd.c, pass around the ParseState pointer in struct CreateStmtContext to save on notation, and add error location pointers to some error reports that didn't have one before. Gurjeet Singh, reviewed by Steve Singer and Tom Lane
2011-01-25 21:42:03 +01:00
* have the same name as the underlying index; therefore, use the index's
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
* existing name as the default constraint name, and if the user
* explicitly gives some other name for the constraint, rename the index
* to match.
Implement ALTER TABLE ADD UNIQUE/PRIMARY KEY USING INDEX. This feature allows a unique or pkey constraint to be created using an already-existing unique index. While the constraint isn't very functionally different from the bare index, it's nice to be able to do that for documentation purposes. The main advantage over just issuing a plain ALTER TABLE ADD UNIQUE/PRIMARY KEY is that the index can be created with CREATE INDEX CONCURRENTLY, so that there is not a long interval where the table is locked against updates. On the way, refactor some of the code in DefineIndex() and index_create() so that we don't have to pass through those functions in order to create the index constraint's catalog entries. Also, in parse_utilcmd.c, pass around the ParseState pointer in struct CreateStmtContext to save on notation, and add error location pointers to some error reports that didn't have one before. Gurjeet Singh, reviewed by Steve Singer and Tom Lane
2011-01-25 21:42:03 +01:00
*/
constraintName = stmt->idxname;
if (constraintName == NULL)
constraintName = indexName;
else if (strcmp(constraintName, indexName) != 0)
{
ereport(NOTICE,
(errmsg("ALTER TABLE / ADD CONSTRAINT USING INDEX will rename index \"%s\" to \"%s\"",
indexName, constraintName)));
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
RenameRelationInternal(index_oid, constraintName, false);
Implement ALTER TABLE ADD UNIQUE/PRIMARY KEY USING INDEX. This feature allows a unique or pkey constraint to be created using an already-existing unique index. While the constraint isn't very functionally different from the bare index, it's nice to be able to do that for documentation purposes. The main advantage over just issuing a plain ALTER TABLE ADD UNIQUE/PRIMARY KEY is that the index can be created with CREATE INDEX CONCURRENTLY, so that there is not a long interval where the table is locked against updates. On the way, refactor some of the code in DefineIndex() and index_create() so that we don't have to pass through those functions in order to create the index constraint's catalog entries. Also, in parse_utilcmd.c, pass around the ParseState pointer in struct CreateStmtContext to save on notation, and add error location pointers to some error reports that didn't have one before. Gurjeet Singh, reviewed by Steve Singer and Tom Lane
2011-01-25 21:42:03 +01:00
}
/* Extra checks needed if making primary key */
if (stmt->primary)
index_check_primary_key(rel, indexInfo, true);
/* Note we currently don't support EXCLUSION constraints here */
if (stmt->primary)
constraintType = CONSTRAINT_PRIMARY;
else
constraintType = CONSTRAINT_UNIQUE;
/* Create the catalog entries for the constraint */
index_constraint_create(rel,
index_oid,
indexInfo,
constraintName,
constraintType,
stmt->deferrable,
stmt->initdeferred,
stmt->primary,
pgindent run for release 9.3 This is the first run of the Perl-based pgindent script. Also update pgindent instructions.
2013-05-29 22:58:43 +02:00
true, /* update pg_index */
true, /* remove old dependencies */
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
allowSystemTableMods,
pgindent run for release 9.3 This is the first run of the Perl-based pgindent script. Also update pgindent instructions.
2013-05-29 22:58:43 +02:00
false); /* is_internal */
Implement ALTER TABLE ADD UNIQUE/PRIMARY KEY USING INDEX. This feature allows a unique or pkey constraint to be created using an already-existing unique index. While the constraint isn't very functionally different from the bare index, it's nice to be able to do that for documentation purposes. The main advantage over just issuing a plain ALTER TABLE ADD UNIQUE/PRIMARY KEY is that the index can be created with CREATE INDEX CONCURRENTLY, so that there is not a long interval where the table is locked against updates. On the way, refactor some of the code in DefineIndex() and index_create() so that we don't have to pass through those functions in order to create the index constraint's catalog entries. Also, in parse_utilcmd.c, pass around the ParseState pointer in struct CreateStmtContext to save on notation, and add error location pointers to some error reports that didn't have one before. Gurjeet Singh, reviewed by Steve Singer and Tom Lane
2011-01-25 21:42:03 +01:00
index_close(indexRel, NoLock);
}
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
/*
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
* ALTER TABLE ADD CONSTRAINT
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static void
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
ATExecAddConstraint(List **wqueue, AlteredTableInfo *tab, Relation rel,
Fix handling of inherited check constraints in ALTER COLUMN TYPE. This case got broken in 8.4 by the addition of an error check that complains if ALTER TABLE ONLY is used on a table that has children. We do use ONLY for this situation, but it's okay because the necessary recursion occurs at a higher level. So we need to have a separate flag to suppress recursion without making the error check. Reported and patched by Pavan Deolasee, with some editorial adjustments by me. Back-patch to 8.4, since this is a regression of functionality that worked in earlier branches.
2012-11-05 19:36:16 +01:00
Constraint *newConstraint, bool recurse, bool is_readd,
LOCKMODE lockmode)
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
{
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
Assert(IsA(newConstraint, Constraint));
/*
* Currently, we only expect to see CONSTR_CHECK and CONSTR_FOREIGN nodes
* arriving here (see the preprocessing done in parse_utilcmd.c). Use a
* switch anyway to make it easier to add more code later.
*/
switch (newConstraint->contype)
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
{
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
case CONSTR_CHECK:
ATAddCheckConstraint(wqueue, tab, rel,
Fix handling of inherited check constraints in ALTER COLUMN TYPE. This case got broken in 8.4 by the addition of an error check that complains if ALTER TABLE ONLY is used on a table that has children. We do use ONLY for this situation, but it's okay because the necessary recursion occurs at a higher level. So we need to have a separate flag to suppress recursion without making the error check. Reported and patched by Pavan Deolasee, with some editorial adjustments by me. Back-patch to 8.4, since this is a regression of functionality that worked in earlier branches.
2012-11-05 19:36:16 +01:00
newConstraint, recurse, false, is_readd,
lockmode);
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
break;
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
case CONSTR_FOREIGN:
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* Note that we currently never recurse for FK constraints, so the
* "recurse" flag is silently ignored.
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
*
* Assign or validate constraint name
*/
if (newConstraint->conname)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
if (ConstraintNameIsUsed(CONSTRAINT_RELATION,
RelationGetRelid(rel),
RelationGetNamespace(rel),
newConstraint->conname))
ereport(ERROR,
(errcode(ERRCODE_DUPLICATE_OBJECT),
errmsg("constraint \"%s\" for relation \"%s\" already exists",
newConstraint->conname,
RelationGetRelationName(rel))));
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
}
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
else
newConstraint->conname =
ChooseConstraintName(RelationGetRelationName(rel),
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
strVal(linitial(newConstraint->fk_attrs)),
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
"fkey",
RelationGetNamespace(rel),
NIL);
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATAddForeignKeyConstraint(tab, rel, newConstraint, lockmode);
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
break;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
default:
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
elog(ERROR, "unrecognized constraint type: %d",
(int) newConstraint->contype);
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
}
}
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
/*
* Add a check constraint to a single table and its children
*
* Subroutine for ATExecAddConstraint.
*
* We must recurse to child tables during execution, rather than using
* ALTER TABLE's normal prep-time recursion. The reason is that all the
* constraints *must* be given the same name, else they won't be seen as
* related later. If the user didn't explicitly specify a name, then
* AddRelationNewConstraints would normally assign different names to the
* child constraints. To fix that, we must capture the name assigned at
* the parent table and pass that down.
Fix handling of inherited check constraints in ALTER COLUMN TYPE. This case got broken in 8.4 by the addition of an error check that complains if ALTER TABLE ONLY is used on a table that has children. We do use ONLY for this situation, but it's okay because the necessary recursion occurs at a higher level. So we need to have a separate flag to suppress recursion without making the error check. Reported and patched by Pavan Deolasee, with some editorial adjustments by me. Back-patch to 8.4, since this is a regression of functionality that worked in earlier branches.
2012-11-05 19:36:16 +01:00
*
* When re-adding a previously existing constraint (during ALTER COLUMN TYPE),
* we don't need to recurse here, because recursion will be carried out at a
* higher level; the constraint name issue doesn't apply because the names
* have already been assigned and are just being re-used. We need a separate
* "is_readd" flag for that; just setting recurse=false would result in an
* error if there are child tables.
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
*/
static void
ATAddCheckConstraint(List **wqueue, AlteredTableInfo *tab, Relation rel,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
Constraint *constr, bool recurse, bool recursing,
Fix handling of inherited check constraints in ALTER COLUMN TYPE. This case got broken in 8.4 by the addition of an error check that complains if ALTER TABLE ONLY is used on a table that has children. We do use ONLY for this situation, but it's okay because the necessary recursion occurs at a higher level. So we need to have a separate flag to suppress recursion without making the error check. Reported and patched by Pavan Deolasee, with some editorial adjustments by me. Back-patch to 8.4, since this is a regression of functionality that worked in earlier branches.
2012-11-05 19:36:16 +01:00
bool is_readd, LOCKMODE lockmode)
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
{
List *newcons;
ListCell *lcon;
List *children;
ListCell *child;
/* At top level, permission check was done in ATPrepCmd, else do it */
if (recursing)
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
ATSimplePermissions(rel, ATT_TABLE);
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
/*
* Call AddRelationNewConstraints to do the work, making sure it works on
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* a copy of the Constraint so transformExpr can't modify the original. It
* returns a list of cooked constraints.
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
*
* If the constraint ends up getting merged with a pre-existing one, it's
* omitted from the returned list, which is what we want: we do not need
* to do any validation work. That can only happen at child tables,
* though, since we disallow merging at the top level.
*/
newcons = AddRelationNewConstraints(rel, NIL,
list_make1(copyObject(constr)),
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
recursing, /* allow_merge */
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
!recursing, /* is_local */
is_readd); /* is_internal */
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
/* Add each to-be-validated constraint to Phase 3's queue */
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
foreach(lcon, newcons)
{
CookedConstraint *ccon = (CookedConstraint *) lfirst(lcon);
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
if (!ccon->skip_validation)
{
NewConstraint *newcon;
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
newcon = (NewConstraint *) palloc0(sizeof(NewConstraint));
newcon->name = ccon->name;
newcon->contype = ccon->contype;
/* ExecQual wants implicit-AND format */
newcon->qual = (Node *) make_ands_implicit((Expr *) ccon->expr);
tab->constraints = lappend(tab->constraints, newcon);
}
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
/* Save the actually assigned name if it was defaulted */
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
if (constr->conname == NULL)
constr->conname = ccon->name;
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
}
/* At this point we must have a locked-down name to use */
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
Assert(constr->conname != NULL);
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
/* Advance command counter in case same table is visited multiple times */
CommandCounterIncrement();
Fix inheritance count tracking in ALTER TABLE .. ADD CONSTRAINT. Without this patch, constraints inherited by children of a parent table which itself has multiple inheritance parents can end up with the wrong coninhcount. After dropping the constraint, the children end up with a leftover copy of the constraint that is not dumped and cannot be dropped. There is a similar problem with ALTER TABLE .. ADD COLUMN, but that looks significantly more difficult to resolve, so I'm committing this fix separately. Back-patch to 8.4, which is the first release that has coninhcount. Report by Hank Enting.
2010-08-03 17:47:02 +02:00
/*
* If the constraint got merged with an existing constraint, we're done.
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
* We mustn't recurse to child tables in this case, because they've
* already got the constraint, and visiting them again would lead to an
* incorrect value for coninhcount.
Fix inheritance count tracking in ALTER TABLE .. ADD CONSTRAINT. Without this patch, constraints inherited by children of a parent table which itself has multiple inheritance parents can end up with the wrong coninhcount. After dropping the constraint, the children end up with a leftover copy of the constraint that is not dumped and cannot be dropped. There is a similar problem with ALTER TABLE .. ADD COLUMN, but that looks significantly more difficult to resolve, so I'm committing this fix separately. Back-patch to 8.4, which is the first release that has coninhcount. Report by Hank Enting.
2010-08-03 17:47:02 +02:00
*/
if (newcons == NIL)
return;
Allow CHECK constraints to be declared ONLY This makes them enforceable only on the parent table, not on children tables. This is useful in various situations, per discussion involving people bitten by the restrictive behavior introduced in 8.4. Message-Id: 8762mp93iw.fsf@comcast.net CAFaPBrSMMpubkGf4zcRL_YL-AERUbYF_-ZNNYfb3CVwwEqc9TQ@mail.gmail.com Authors: Nikhil Sontakke, Alex Hunsaker Reviewed by Robert Haas and myself
2011-12-05 19:10:18 +01:00
/*
Fix handling of inherited check constraints in ALTER COLUMN TYPE. This case got broken in 8.4 by the addition of an error check that complains if ALTER TABLE ONLY is used on a table that has children. We do use ONLY for this situation, but it's okay because the necessary recursion occurs at a higher level. So we need to have a separate flag to suppress recursion without making the error check. Reported and patched by Pavan Deolasee, with some editorial adjustments by me. Back-patch to 8.4, since this is a regression of functionality that worked in earlier branches.
2012-11-05 19:36:16 +01:00
* If adding a NO INHERIT constraint, no need to find our children.
* Likewise, in a re-add operation, we don't need to recurse (that will be
* handled at higher levels).
Allow CHECK constraints to be declared ONLY This makes them enforceable only on the parent table, not on children tables. This is useful in various situations, per discussion involving people bitten by the restrictive behavior introduced in 8.4. Message-Id: 8762mp93iw.fsf@comcast.net CAFaPBrSMMpubkGf4zcRL_YL-AERUbYF_-ZNNYfb3CVwwEqc9TQ@mail.gmail.com Authors: Nikhil Sontakke, Alex Hunsaker Reviewed by Robert Haas and myself
2011-12-05 19:10:18 +01:00
*/
Fix handling of inherited check constraints in ALTER COLUMN TYPE. This case got broken in 8.4 by the addition of an error check that complains if ALTER TABLE ONLY is used on a table that has children. We do use ONLY for this situation, but it's okay because the necessary recursion occurs at a higher level. So we need to have a separate flag to suppress recursion without making the error check. Reported and patched by Pavan Deolasee, with some editorial adjustments by me. Back-patch to 8.4, since this is a regression of functionality that worked in earlier branches.
2012-11-05 19:36:16 +01:00
if (constr->is_no_inherit || is_readd)
Allow CHECK constraints to be declared ONLY This makes them enforceable only on the parent table, not on children tables. This is useful in various situations, per discussion involving people bitten by the restrictive behavior introduced in 8.4. Message-Id: 8762mp93iw.fsf@comcast.net CAFaPBrSMMpubkGf4zcRL_YL-AERUbYF_-ZNNYfb3CVwwEqc9TQ@mail.gmail.com Authors: Nikhil Sontakke, Alex Hunsaker Reviewed by Robert Haas and myself
2011-12-05 19:10:18 +01:00
return;
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
/*
* Propagate to children as appropriate. Unlike most other ALTER
* routines, we have to do this one level of recursion at a time; we can't
* use find_all_inheritors to do it in one pass.
*/
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
children = find_inheritance_children(RelationGetRelid(rel), lockmode);
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
Recast "ONLY" column CHECK constraints as NO INHERIT The original syntax wasn't universally loved, and it didn't allow its usage in CREATE TABLE, only ALTER TABLE. It now works everywhere, and it also allows using ALTER TABLE ONLY to add an uninherited CHECK constraint, per discussion. The pg_constraint column has accordingly been renamed connoinherit. This commit partly reverts some of the changes in 61d81bd28dbec65a6b144e0cd3d0bfe25913c3ac, particularly some pg_dump and psql bits, because now pg_get_constraintdef includes the necessary NO INHERIT within the constraint definition. Author: Nikhil Sontakke Some tweaks by me
2012-04-21 04:46:20 +02:00
/*
* Check if ONLY was specified with ALTER TABLE. If so, allow the
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* contraint creation only if there are no children currently. Error out
Recast "ONLY" column CHECK constraints as NO INHERIT The original syntax wasn't universally loved, and it didn't allow its usage in CREATE TABLE, only ALTER TABLE. It now works everywhere, and it also allows using ALTER TABLE ONLY to add an uninherited CHECK constraint, per discussion. The pg_constraint column has accordingly been renamed connoinherit. This commit partly reverts some of the changes in 61d81bd28dbec65a6b144e0cd3d0bfe25913c3ac, particularly some pg_dump and psql bits, because now pg_get_constraintdef includes the necessary NO INHERIT within the constraint definition. Author: Nikhil Sontakke Some tweaks by me
2012-04-21 04:46:20 +02:00
* otherwise.
*/
if (!recurse && children != NIL)
ereport(ERROR,
(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
errmsg("constraint must be added to child tables too")));
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
foreach(child, children)
{
Oid childrelid = lfirst_oid(child);
Relation childrel;
AlteredTableInfo *childtab;
Modify find_inheritance_children() and find_all_inheritors() to add the ability to lock relations as they scan pg_inherits, and to ignore any relations that have disappeared by the time we get lock on them. This makes uses of these functions safe against concurrent DROP operations on child tables: we will effectively ignore any just-dropped child, rather than possibly throwing an error as in recent bug report from Thomas Johansson (and similar past complaints). The behavior should not change otherwise, since the code was acquiring those same locks anyway, just a little bit later. An exception is LockTableCommand(), which is still behaving unsafely; but that seems to require some more discussion before we change it.
2009-05-12 05:11:02 +02:00
/* find_inheritance_children already got lock */
childrel = heap_open(childrelid, NoLock);
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
CheckTableNotInUse(childrel, "ALTER TABLE");
/* Find or create work queue entry for this table */
childtab = ATGetQueueEntry(wqueue, childrel);
/* Recurse to child */
ATAddCheckConstraint(wqueue, childtab, childrel,
Fix handling of inherited check constraints in ALTER COLUMN TYPE. This case got broken in 8.4 by the addition of an error check that complains if ALTER TABLE ONLY is used on a table that has children. We do use ONLY for this situation, but it's okay because the necessary recursion occurs at a higher level. So we need to have a separate flag to suppress recursion without making the error check. Reported and patched by Pavan Deolasee, with some editorial adjustments by me. Back-patch to 8.4, since this is a regression of functionality that worked in earlier branches.
2012-11-05 19:36:16 +01:00
constr, recurse, true, is_readd, lockmode);
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
heap_close(childrel, NoLock);
}
}
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
/*
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* Add a foreign-key constraint to a single table
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
*
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* Subroutine for ATExecAddConstraint. Must already hold exclusive
Support column-level privileges, as required by SQL standard. Stephen Frost, with help from KaiGai Kohei and others
2009-01-22 21:16:10 +01:00
* lock on the rel, and have done appropriate validity checks for it.
* We do permissions checks here, however.
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
*/
static void
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
ATAddForeignKeyConstraint(AlteredTableInfo *tab, Relation rel,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
Constraint *fkconstraint, LOCKMODE lockmode)
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
{
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Relation pkrel;
int16 pkattnum[INDEX_MAX_KEYS];
int16 fkattnum[INDEX_MAX_KEYS];
Oid pktypoid[INDEX_MAX_KEYS];
Oid fktypoid[INDEX_MAX_KEYS];
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
Oid opclasses[INDEX_MAX_KEYS];
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
Oid pfeqoperators[INDEX_MAX_KEYS];
Oid ppeqoperators[INDEX_MAX_KEYS];
Oid ffeqoperators[INDEX_MAX_KEYS];
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
int i;
int numfks,
numpks;
Oid indexOid;
Oid constrOid;
ALTER TABLE: skip FK validation when it's safe to do so We already skip rewriting the table in these cases, but we still force a whole table scan to validate the data. This can be skipped, and thus we can make the whole ALTER TABLE operation just do some catalog touches instead of scanning the table, when these two conditions hold: (a) Old and new pg_constraint.conpfeqop match exactly. This is actually stronger than needed; we could loosen things by way of operator families, but it'd require a lot more effort. (b) The functions, if any, implementing a cast from the foreign type to the primary opcintype are the same. For this purpose, we can consider a binary coercion equivalent to an exact type match. When the opcintype is polymorphic, require that the old and new foreign types match exactly. (Since ri_triggers.c does use the executor, the stronger check for polymorphic types is no mere future-proofing. However, no core type exercises its necessity.) Author: Noah Misch Committer's note: catalog version bumped due to change of the Constraint node. I can't actually find any way to have such a node in a stored rule, but given that we have "out" support for them, better be safe.
2012-02-27 22:28:00 +01:00
bool old_check_ok;
ListCell *old_pfeqop_item = list_head(fkconstraint->old_conpfeqop);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
Finish disabling reduced-lock-levels-for-DDL feature. Previous patch only covered the ALTER TABLE changes, not changes in other commands; and it neglected to revert the documentation changes.
2011-07-07 19:14:46 +02:00
/*
* Grab an exclusive lock on the pk table, so that someone doesn't delete
* rows out from under us. (Although a lesser lock would do for that
* purpose, we'll need exclusive lock anyway to add triggers to the pk
* table; trying to start with a lesser lock will just create a risk of
* deadlock.)
*/
pkrel = heap_openrv(fkconstraint->pktable, AccessExclusiveLock);
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
/*
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* Validity checks (permission checks wait till we have the column
* numbers)
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (pkrel->rd_rel->relkind != RELKIND_RELATION)
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("referenced relation \"%s\" is not a table",
RelationGetRelationName(pkrel))));
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (!allowSystemTableMods && IsSystemRelation(pkrel))
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
Adjust 'permission denied' messages to be more useful and consistent.
2003-08-01 02:15:26 +02:00
errmsg("permission denied: \"%s\" is a system catalog",
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
RelationGetRelationName(pkrel))));
Disallow foreign-key references from temp tables to permanent tables. Per recent discussion, this does not work because other backends can't reliably see tuples in a temp table and so cannot run the RI checks correctly. Seems better to disallow this case than go back to accessing temp tables through shared buffers. Also, disallow FK references to ON COMMIT DELETE ROWS tables. We already caught this problem for normal TRUNCATE, but the path used by ON COMMIT didn't check.
2003-09-19 23:04:20 +02:00
/*
Support unlogged tables. The contents of an unlogged table are WAL-logged; thus, they are not available on standby servers and are truncated whenever the database system enters recovery. Indexes on unlogged tables are also unlogged. Unlogged GiST indexes are not currently supported.
2010-12-29 12:48:53 +01:00
* References from permanent or unlogged tables to temp tables, and from
* permanent tables to unlogged tables, are disallowed because the
* referenced data can vanish out from under us. References from temp
* tables to any other table type are also disallowed, because other
* backends might need to run the RI triggers on the perm table, but they
* can't reliably see tuples in the local buffers of other backends.
Disallow foreign-key references from temp tables to permanent tables. Per recent discussion, this does not work because other backends can't reliably see tuples in a temp table and so cannot run the RI checks correctly. Seems better to disallow this case than go back to accessing temp tables through shared buffers. Also, disallow FK references to ON COMMIT DELETE ROWS tables. We already caught this problem for normal TRUNCATE, but the path used by ON COMMIT didn't check.
2003-09-19 23:04:20 +02:00
*/
Generalize concept of temporary relations to "relation persistence". This commit replaces pg_class.relistemp with pg_class.relpersistence; and also modifies the RangeVar node type to carry relpersistence rather than istemp. It also removes removes rd_istemp from RelationData and instead performs the correct computation based on relpersistence. For clarity, we add three new macros: RelationNeedsWAL(), RelationUsesLocalBuffers(), and RelationUsesTempNamespace(), so that we can clarify the purpose of each check that previous depended on rd_istemp. This is intended as infrastructure for the upcoming unlogged tables patch, as well as for future possible work on global temporary tables.
2010-12-13 18:34:26 +01:00
switch (rel->rd_rel->relpersistence)
Disallow foreign-key references from temp tables to permanent tables. Per recent discussion, this does not work because other backends can't reliably see tuples in a temp table and so cannot run the RI checks correctly. Seems better to disallow this case than go back to accessing temp tables through shared buffers. Also, disallow FK references to ON COMMIT DELETE ROWS tables. We already caught this problem for normal TRUNCATE, but the path used by ON COMMIT didn't check.
2003-09-19 23:04:20 +02:00
{
Generalize concept of temporary relations to "relation persistence". This commit replaces pg_class.relistemp with pg_class.relpersistence; and also modifies the RangeVar node type to carry relpersistence rather than istemp. It also removes removes rd_istemp from RelationData and instead performs the correct computation based on relpersistence. For clarity, we add three new macros: RelationNeedsWAL(), RelationUsesLocalBuffers(), and RelationUsesTempNamespace(), so that we can clarify the purpose of each check that previous depended on rd_istemp. This is intended as infrastructure for the upcoming unlogged tables patch, as well as for future possible work on global temporary tables.
2010-12-13 18:34:26 +01:00
case RELPERSISTENCE_PERMANENT:
if (pkrel->rd_rel->relpersistence != RELPERSISTENCE_PERMANENT)
ereport(ERROR,
(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
errmsg("constraints on permanent tables may reference only permanent tables")));
break;
Support unlogged tables. The contents of an unlogged table are WAL-logged; thus, they are not available on standby servers and are truncated whenever the database system enters recovery. Indexes on unlogged tables are also unlogged. Unlogged GiST indexes are not currently supported.
2010-12-29 12:48:53 +01:00
case RELPERSISTENCE_UNLOGGED:
if (pkrel->rd_rel->relpersistence != RELPERSISTENCE_PERMANENT
&& pkrel->rd_rel->relpersistence != RELPERSISTENCE_UNLOGGED)
ereport(ERROR,
(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
errmsg("constraints on unlogged tables may reference only permanent or unlogged tables")));
break;
Generalize concept of temporary relations to "relation persistence". This commit replaces pg_class.relistemp with pg_class.relpersistence; and also modifies the RangeVar node type to carry relpersistence rather than istemp. It also removes removes rd_istemp from RelationData and instead performs the correct computation based on relpersistence. For clarity, we add three new macros: RelationNeedsWAL(), RelationUsesLocalBuffers(), and RelationUsesTempNamespace(), so that we can clarify the purpose of each check that previous depended on rd_istemp. This is intended as infrastructure for the upcoming unlogged tables patch, as well as for future possible work on global temporary tables.
2010-12-13 18:34:26 +01:00
case RELPERSISTENCE_TEMP:
if (pkrel->rd_rel->relpersistence != RELPERSISTENCE_TEMP)
ereport(ERROR,
(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
errmsg("constraints on temporary tables may reference only temporary tables")));
Fix failure to ignore leftover temp tables after a server crash. During crash recovery, we remove disk files belonging to temporary tables, but the system catalog entries for such tables are intentionally not cleaned up right away. Instead, the first backend that uses a temp schema is expected to clean out any leftover objects therein. This approach requires that we be careful to ignore leftover temp tables (since any actual access attempt would fail), *even if their BackendId matches our session*, if we have not yet established use of the session's corresponding temp schema. That worked fine in the past, but was broken by commit debcec7dc31a992703911a9953e299c8d730c778 which incorrectly removed the rd_islocaltemp relcache flag. Put it back, and undo various changes that substituted tests like "rel->rd_backend == MyBackendId" for use of a state-aware flag. Per trouble report from Heikki Linnakangas. Back-patch to 9.1 where the erroneous change was made. In the back branches, be careful to add rd_islocaltemp in a spot in the struct that was alignment padding before, so as not to break existing add-on code.
2012-12-18 02:15:32 +01:00
if (!pkrel->rd_islocaltemp || !rel->rd_islocaltemp)
ereport(ERROR,
(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
errmsg("constraints on temporary tables must involve temporary tables of this session")));
Generalize concept of temporary relations to "relation persistence". This commit replaces pg_class.relistemp with pg_class.relpersistence; and also modifies the RangeVar node type to carry relpersistence rather than istemp. It also removes removes rd_istemp from RelationData and instead performs the correct computation based on relpersistence. For clarity, we add three new macros: RelationNeedsWAL(), RelationUsesLocalBuffers(), and RelationUsesTempNamespace(), so that we can clarify the purpose of each check that previous depended on rd_istemp. This is intended as infrastructure for the upcoming unlogged tables patch, as well as for future possible work on global temporary tables.
2010-12-13 18:34:26 +01:00
break;
Disallow foreign-key references from temp tables to permanent tables. Per recent discussion, this does not work because other backends can't reliably see tuples in a temp table and so cannot run the RI checks correctly. Seems better to disallow this case than go back to accessing temp tables through shared buffers. Also, disallow FK references to ON COMMIT DELETE ROWS tables. We already caught this problem for normal TRUNCATE, but the path used by ON COMMIT didn't check.
2003-09-19 23:04:20 +02:00
}
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Look up the referencing attributes to make sure they exist, and record
* their attnums and type OIDs.
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
*/
Generate a WARNING when the column types in a foreign key constraint are incompatible enough to prevent indexscanning the referenced table. Also, improve the error message that pops out when we can't implement the FK at all for lack of a usable equality operator. Fabien Coelho, with some review by Tom Lane.
2004-03-13 23:09:14 +01:00
MemSet(pkattnum, 0, sizeof(pkattnum));
MemSet(fkattnum, 0, sizeof(fkattnum));
MemSet(pktypoid, 0, sizeof(pktypoid));
MemSet(fktypoid, 0, sizeof(fktypoid));
MemSet(opclasses, 0, sizeof(opclasses));
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
MemSet(pfeqoperators, 0, sizeof(pfeqoperators));
MemSet(ppeqoperators, 0, sizeof(ppeqoperators));
MemSet(ffeqoperators, 0, sizeof(ffeqoperators));
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
numfks = transformColumnNameList(RelationGetRelid(rel),
fkconstraint->fk_attrs,
fkattnum, fktypoid);
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* If the attribute list for the referenced table was omitted, lookup the
* definition of the primary key and use it. Otherwise, validate the
* supplied attribute list. In either case, discover the index OID and
* index opclasses, and the attnums and type OIDs of the attributes.
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
*/
if (fkconstraint->pk_attrs == NIL)
{
numpks = transformFkeyGetPrimaryKey(pkrel, &indexOid,
&fkconstraint->pk_attrs,
Generate a WARNING when the column types in a foreign key constraint are incompatible enough to prevent indexscanning the referenced table. Also, improve the error message that pops out when we can't implement the FK at all for lack of a usable equality operator. Fabien Coelho, with some review by Tom Lane.
2004-03-13 23:09:14 +01:00
pkattnum, pktypoid,
opclasses);
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
}
else
{
numpks = transformColumnNameList(RelationGetRelid(pkrel),
fkconstraint->pk_attrs,
pkattnum, pktypoid);
/* Look for an index matching the column list */
Generate a WARNING when the column types in a foreign key constraint are incompatible enough to prevent indexscanning the referenced table. Also, improve the error message that pops out when we can't implement the FK at all for lack of a usable equality operator. Fabien Coelho, with some review by Tom Lane.
2004-03-13 23:09:14 +01:00
indexOid = transformFkeyCheckAttrs(pkrel, numpks, pkattnum,
opclasses);
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
}
Support column-level privileges, as required by SQL standard. Stephen Frost, with help from KaiGai Kohei and others
2009-01-22 21:16:10 +01:00
/*
* Now we can check permissions.
*/
checkFkeyPermissions(pkrel, pkattnum, numpks);
checkFkeyPermissions(rel, fkattnum, numfks);
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
/*
* Look up the equality operators to use in the constraint.
*
Fix new RI operator selection code to do the right thing when working with 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.
2007-02-16 23:04:02 +01:00
* Note that we have to be careful about the difference between the actual
* PK column type and the opclass' declared input type, which might be
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* only binary-compatible with it. The declared opcintype is the right
Fix new RI operator selection code to do the right thing when working with 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.
2007-02-16 23:04:02 +01:00
* thing to probe pg_amop with.
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
*/
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
if (numfks != numpks)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_INVALID_FOREIGN_KEY),
Message editing: remove gratuitous variations in message wording, standardize terms, add some clarifications, fix some untranslatable attempts at dynamic message building.
2003-09-25 08:58:07 +02:00
errmsg("number of referencing and referenced columns for foreign key disagree")));
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
ALTER TABLE: skip FK validation when it's safe to do so We already skip rewriting the table in these cases, but we still force a whole table scan to validate the data. This can be skipped, and thus we can make the whole ALTER TABLE operation just do some catalog touches instead of scanning the table, when these two conditions hold: (a) Old and new pg_constraint.conpfeqop match exactly. This is actually stronger than needed; we could loosen things by way of operator families, but it'd require a lot more effort. (b) The functions, if any, implementing a cast from the foreign type to the primary opcintype are the same. For this purpose, we can consider a binary coercion equivalent to an exact type match. When the opcintype is polymorphic, require that the old and new foreign types match exactly. (Since ri_triggers.c does use the executor, the stronger check for polymorphic types is no mere future-proofing. However, no core type exercises its necessity.) Author: Noah Misch Committer's note: catalog version bumped due to change of the Constraint node. I can't actually find any way to have such a node in a stored rule, but given that we have "out" support for them, better be safe.
2012-02-27 22:28:00 +01:00
/*
* On the strength of a previous constraint, we might avoid scanning
* tables to validate this one. See below.
*/
old_check_ok = (fkconstraint->old_conpfeqop != NIL);
Assert(!old_check_ok || numfks == list_length(fkconstraint->old_conpfeqop));
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
for (i = 0; i < numpks; i++)
{
Fix new RI operator selection code to do the right thing when working with 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.
2007-02-16 23:04:02 +01:00
Oid pktype = pktypoid[i];
Oid fktype = fktypoid[i];
Oid fktyped;
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
HeapTuple cla_ht;
Form_pg_opclass cla_tup;
Oid amid;
Oid opfamily;
Fix new RI operator selection code to do the right thing when working with 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.
2007-02-16 23:04:02 +01:00
Oid opcintype;
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
Oid pfeqop;
Oid ppeqop;
Oid ffeqop;
int16 eqstrategy;
ALTER TABLE: skip FK validation when it's safe to do so We already skip rewriting the table in these cases, but we still force a whole table scan to validate the data. This can be skipped, and thus we can make the whole ALTER TABLE operation just do some catalog touches instead of scanning the table, when these two conditions hold: (a) Old and new pg_constraint.conpfeqop match exactly. This is actually stronger than needed; we could loosen things by way of operator families, but it'd require a lot more effort. (b) The functions, if any, implementing a cast from the foreign type to the primary opcintype are the same. For this purpose, we can consider a binary coercion equivalent to an exact type match. When the opcintype is polymorphic, require that the old and new foreign types match exactly. (Since ri_triggers.c does use the executor, the stronger check for polymorphic types is no mere future-proofing. However, no core type exercises its necessity.) Author: Noah Misch Committer's note: catalog version bumped due to change of the Constraint node. I can't actually find any way to have such a node in a stored rule, but given that we have "out" support for them, better be safe.
2012-02-27 22:28:00 +01:00
Oid pfeqop_right;
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
/* We need several fields out of the pg_opclass entry */
Wrap calls to SearchSysCache and related functions using macros. The purpose of this change is to eliminate the need for every caller of SearchSysCache, SearchSysCacheCopy, SearchSysCacheExists, GetSysCacheOid, and SearchSysCacheList to know the maximum number of allowable keys for a syscache entry (currently 4). This will make it far easier to increase the maximum number of keys in a future release should we choose to do so, and it makes the code shorter, too. Design and review by Tom Lane.
2010-02-14 19:42:19 +01:00
cla_ht = SearchSysCache1(CLAOID, ObjectIdGetDatum(opclasses[i]));
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
if (!HeapTupleIsValid(cla_ht))
elog(ERROR, "cache lookup failed for opclass %u", opclasses[i]);
cla_tup = (Form_pg_opclass) GETSTRUCT(cla_ht);
amid = cla_tup->opcmethod;
opfamily = cla_tup->opcfamily;
Fix new RI operator selection code to do the right thing when working with 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.
2007-02-16 23:04:02 +01:00
opcintype = cla_tup->opcintype;
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
ReleaseSysCache(cla_ht);
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
/*
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
* Check it's a btree; currently this can never fail since no other
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* index AMs support unique indexes. If we ever did have other types
* of unique indexes, we'd need a way to determine which operator
* strategy number is equality. (Is it reasonable to insist that
* every such index AM use btree's number for equality?)
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
*/
if (amid != BTREE_AM_OID)
elog(ERROR, "only b-tree indexes are supported for foreign keys");
eqstrategy = BTEqualStrategyNumber;
/*
Fix new RI operator selection code to do the right thing when working with 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.
2007-02-16 23:04:02 +01:00
* There had better be a primary equality operator for the index.
* We'll use it for PK = PK comparisons.
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
*/
Fix new RI operator selection code to do the right thing when working with 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.
2007-02-16 23:04:02 +01:00
ppeqop = get_opfamily_member(opfamily, opcintype, opcintype,
eqstrategy);
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
if (!OidIsValid(ppeqop))
elog(ERROR, "missing operator %d(%u,%u) in opfamily %u",
Fix new RI operator selection code to do the right thing when working with 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.
2007-02-16 23:04:02 +01:00
eqstrategy, opcintype, opcintype, opfamily);
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
/*
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* Are there equality operators that take exactly the FK type? Assume
* we should look through any domain here.
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
*/
Fix new RI operator selection code to do the right thing when working with 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.
2007-02-16 23:04:02 +01:00
fktyped = getBaseType(fktype);
Generate a WARNING when the column types in a foreign key constraint are incompatible enough to prevent indexscanning the referenced table. Also, improve the error message that pops out when we can't implement the FK at all for lack of a usable equality operator. Fabien Coelho, with some review by Tom Lane.
2004-03-13 23:09:14 +01:00
Fix new RI operator selection code to do the right thing when working with 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.
2007-02-16 23:04:02 +01:00
pfeqop = get_opfamily_member(opfamily, opcintype, fktyped,
eqstrategy);
if (OidIsValid(pfeqop))
ALTER TABLE: skip FK validation when it's safe to do so We already skip rewriting the table in these cases, but we still force a whole table scan to validate the data. This can be skipped, and thus we can make the whole ALTER TABLE operation just do some catalog touches instead of scanning the table, when these two conditions hold: (a) Old and new pg_constraint.conpfeqop match exactly. This is actually stronger than needed; we could loosen things by way of operator families, but it'd require a lot more effort. (b) The functions, if any, implementing a cast from the foreign type to the primary opcintype are the same. For this purpose, we can consider a binary coercion equivalent to an exact type match. When the opcintype is polymorphic, require that the old and new foreign types match exactly. (Since ri_triggers.c does use the executor, the stronger check for polymorphic types is no mere future-proofing. However, no core type exercises its necessity.) Author: Noah Misch Committer's note: catalog version bumped due to change of the Constraint node. I can't actually find any way to have such a node in a stored rule, but given that we have "out" support for them, better be safe.
2012-02-27 22:28:00 +01:00
{
pfeqop_right = fktyped;
Fix new RI operator selection code to do the right thing when working with 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.
2007-02-16 23:04:02 +01:00
ffeqop = get_opfamily_member(opfamily, fktyped, fktyped,
eqstrategy);
ALTER TABLE: skip FK validation when it's safe to do so We already skip rewriting the table in these cases, but we still force a whole table scan to validate the data. This can be skipped, and thus we can make the whole ALTER TABLE operation just do some catalog touches instead of scanning the table, when these two conditions hold: (a) Old and new pg_constraint.conpfeqop match exactly. This is actually stronger than needed; we could loosen things by way of operator families, but it'd require a lot more effort. (b) The functions, if any, implementing a cast from the foreign type to the primary opcintype are the same. For this purpose, we can consider a binary coercion equivalent to an exact type match. When the opcintype is polymorphic, require that the old and new foreign types match exactly. (Since ri_triggers.c does use the executor, the stronger check for polymorphic types is no mere future-proofing. However, no core type exercises its necessity.) Author: Noah Misch Committer's note: catalog version bumped due to change of the Constraint node. I can't actually find any way to have such a node in a stored rule, but given that we have "out" support for them, better be safe.
2012-02-27 22:28:00 +01:00
}
Fix new RI operator selection code to do the right thing when working with 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.
2007-02-16 23:04:02 +01:00
else
ALTER TABLE: skip FK validation when it's safe to do so We already skip rewriting the table in these cases, but we still force a whole table scan to validate the data. This can be skipped, and thus we can make the whole ALTER TABLE operation just do some catalog touches instead of scanning the table, when these two conditions hold: (a) Old and new pg_constraint.conpfeqop match exactly. This is actually stronger than needed; we could loosen things by way of operator families, but it'd require a lot more effort. (b) The functions, if any, implementing a cast from the foreign type to the primary opcintype are the same. For this purpose, we can consider a binary coercion equivalent to an exact type match. When the opcintype is polymorphic, require that the old and new foreign types match exactly. (Since ri_triggers.c does use the executor, the stronger check for polymorphic types is no mere future-proofing. However, no core type exercises its necessity.) Author: Noah Misch Committer's note: catalog version bumped due to change of the Constraint node. I can't actually find any way to have such a node in a stored rule, but given that we have "out" support for them, better be safe.
2012-02-27 22:28:00 +01:00
{
/* keep compiler quiet */
pfeqop_right = InvalidOid;
ffeqop = InvalidOid;
}
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
if (!(OidIsValid(pfeqop) && OidIsValid(ffeqop)))
{
/*
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* Otherwise, look for an implicit cast from the FK type to the
* opcintype, and if found, use the primary equality operator.
Coercion sanity check in ri_HashCompareOp failed to allow for enums, as per example from Rod Taylor. On reflection the correct test here is for any polymorphic type, not specifically ANYARRAY as in the original coding.
2008-05-19 06:14:24 +02:00
* This is a bit tricky because opcintype might be a polymorphic
* type such as ANYARRAY or ANYENUM; so what we have to test is
* whether the two actual column types can be concurrently cast to
* that type. (Otherwise, we'd fail to reject combinations such
* as int[] and point[].)
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
*/
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
Oid input_typeids[2];
Oid target_typeids[2];
Fix new RI operator selection code to do the right thing when working with 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.
2007-02-16 23:04:02 +01:00
input_typeids[0] = pktype;
input_typeids[1] = fktype;
target_typeids[0] = opcintype;
target_typeids[1] = opcintype;
if (can_coerce_type(2, input_typeids, target_typeids,
COERCION_IMPLICIT))
ALTER TABLE: skip FK validation when it's safe to do so We already skip rewriting the table in these cases, but we still force a whole table scan to validate the data. This can be skipped, and thus we can make the whole ALTER TABLE operation just do some catalog touches instead of scanning the table, when these two conditions hold: (a) Old and new pg_constraint.conpfeqop match exactly. This is actually stronger than needed; we could loosen things by way of operator families, but it'd require a lot more effort. (b) The functions, if any, implementing a cast from the foreign type to the primary opcintype are the same. For this purpose, we can consider a binary coercion equivalent to an exact type match. When the opcintype is polymorphic, require that the old and new foreign types match exactly. (Since ri_triggers.c does use the executor, the stronger check for polymorphic types is no mere future-proofing. However, no core type exercises its necessity.) Author: Noah Misch Committer's note: catalog version bumped due to change of the Constraint node. I can't actually find any way to have such a node in a stored rule, but given that we have "out" support for them, better be safe.
2012-02-27 22:28:00 +01:00
{
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
pfeqop = ffeqop = ppeqop;
ALTER TABLE: skip FK validation when it's safe to do so We already skip rewriting the table in these cases, but we still force a whole table scan to validate the data. This can be skipped, and thus we can make the whole ALTER TABLE operation just do some catalog touches instead of scanning the table, when these two conditions hold: (a) Old and new pg_constraint.conpfeqop match exactly. This is actually stronger than needed; we could loosen things by way of operator families, but it'd require a lot more effort. (b) The functions, if any, implementing a cast from the foreign type to the primary opcintype are the same. For this purpose, we can consider a binary coercion equivalent to an exact type match. When the opcintype is polymorphic, require that the old and new foreign types match exactly. (Since ri_triggers.c does use the executor, the stronger check for polymorphic types is no mere future-proofing. However, no core type exercises its necessity.) Author: Noah Misch Committer's note: catalog version bumped due to change of the Constraint node. I can't actually find any way to have such a node in a stored rule, but given that we have "out" support for them, better be safe.
2012-02-27 22:28:00 +01:00
pfeqop_right = opcintype;
}
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
}
if (!(OidIsValid(pfeqop) && OidIsValid(ffeqop)))
Generate a WARNING when the column types in a foreign key constraint are incompatible enough to prevent indexscanning the referenced table. Also, improve the error message that pops out when we can't implement the FK at all for lack of a usable equality operator. Fabien Coelho, with some review by Tom Lane.
2004-03-13 23:09:14 +01:00
ereport(ERROR,
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
(errcode(ERRCODE_DATATYPE_MISMATCH),
Generate a WARNING when the column types in a foreign key constraint are incompatible enough to prevent indexscanning the referenced table. Also, improve the error message that pops out when we can't implement the FK at all for lack of a usable equality operator. Fabien Coelho, with some review by Tom Lane.
2004-03-13 23:09:14 +01:00
errmsg("foreign key constraint \"%s\" "
"cannot be implemented",
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
fkconstraint->conname),
Generate a WARNING when the column types in a foreign key constraint are incompatible enough to prevent indexscanning the referenced table. Also, improve the error message that pops out when we can't implement the FK at all for lack of a usable equality operator. Fabien Coelho, with some review by Tom Lane.
2004-03-13 23:09:14 +01:00
errdetail("Key columns \"%s\" and \"%s\" "
"are of incompatible types: %s and %s.",
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
strVal(list_nth(fkconstraint->fk_attrs, i)),
strVal(list_nth(fkconstraint->pk_attrs, i)),
Fix new RI operator selection code to do the right thing when working with 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.
2007-02-16 23:04:02 +01:00
format_type_be(fktype),
format_type_be(pktype))));
Generate a WARNING when the column types in a foreign key constraint are incompatible enough to prevent indexscanning the referenced table. Also, improve the error message that pops out when we can't implement the FK at all for lack of a usable equality operator. Fabien Coelho, with some review by Tom Lane.
2004-03-13 23:09:14 +01:00
ALTER TABLE: skip FK validation when it's safe to do so We already skip rewriting the table in these cases, but we still force a whole table scan to validate the data. This can be skipped, and thus we can make the whole ALTER TABLE operation just do some catalog touches instead of scanning the table, when these two conditions hold: (a) Old and new pg_constraint.conpfeqop match exactly. This is actually stronger than needed; we could loosen things by way of operator families, but it'd require a lot more effort. (b) The functions, if any, implementing a cast from the foreign type to the primary opcintype are the same. For this purpose, we can consider a binary coercion equivalent to an exact type match. When the opcintype is polymorphic, require that the old and new foreign types match exactly. (Since ri_triggers.c does use the executor, the stronger check for polymorphic types is no mere future-proofing. However, no core type exercises its necessity.) Author: Noah Misch Committer's note: catalog version bumped due to change of the Constraint node. I can't actually find any way to have such a node in a stored rule, but given that we have "out" support for them, better be safe.
2012-02-27 22:28:00 +01:00
if (old_check_ok)
{
/*
* When a pfeqop changes, revalidate the constraint. We could
* permit intra-opfamily changes, but that adds subtle complexity
* without any concrete benefit for core types. We need not
* assess ppeqop or ffeqop, which RI_Initial_Check() does not use.
*/
old_check_ok = (pfeqop == lfirst_oid(old_pfeqop_item));
old_pfeqop_item = lnext(old_pfeqop_item);
}
if (old_check_ok)
{
Oid old_fktype;
Oid new_fktype;
CoercionPathType old_pathtype;
CoercionPathType new_pathtype;
Oid old_castfunc;
Oid new_castfunc;
/*
* Identify coercion pathways from each of the old and new FK-side
* column types to the right (foreign) operand type of the pfeqop.
* We may assume that pg_constraint.conkey is not changing.
*/
old_fktype = tab->oldDesc->attrs[fkattnum[i] - 1]->atttypid;
new_fktype = fktype;
old_pathtype = findFkeyCast(pfeqop_right, old_fktype,
&old_castfunc);
new_pathtype = findFkeyCast(pfeqop_right, new_fktype,
&new_castfunc);
/*
* Upon a change to the cast from the FK column to its pfeqop
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* operand, revalidate the constraint. For this evaluation, a
ALTER TABLE: skip FK validation when it's safe to do so We already skip rewriting the table in these cases, but we still force a whole table scan to validate the data. This can be skipped, and thus we can make the whole ALTER TABLE operation just do some catalog touches instead of scanning the table, when these two conditions hold: (a) Old and new pg_constraint.conpfeqop match exactly. This is actually stronger than needed; we could loosen things by way of operator families, but it'd require a lot more effort. (b) The functions, if any, implementing a cast from the foreign type to the primary opcintype are the same. For this purpose, we can consider a binary coercion equivalent to an exact type match. When the opcintype is polymorphic, require that the old and new foreign types match exactly. (Since ri_triggers.c does use the executor, the stronger check for polymorphic types is no mere future-proofing. However, no core type exercises its necessity.) Author: Noah Misch Committer's note: catalog version bumped due to change of the Constraint node. I can't actually find any way to have such a node in a stored rule, but given that we have "out" support for them, better be safe.
2012-02-27 22:28:00 +01:00
* binary coercion cast is equivalent to no cast at all. While
* type implementors should design implicit casts with an eye
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* toward consistency of operations like equality, we cannot
* assume here that they have done so.
ALTER TABLE: skip FK validation when it's safe to do so We already skip rewriting the table in these cases, but we still force a whole table scan to validate the data. This can be skipped, and thus we can make the whole ALTER TABLE operation just do some catalog touches instead of scanning the table, when these two conditions hold: (a) Old and new pg_constraint.conpfeqop match exactly. This is actually stronger than needed; we could loosen things by way of operator families, but it'd require a lot more effort. (b) The functions, if any, implementing a cast from the foreign type to the primary opcintype are the same. For this purpose, we can consider a binary coercion equivalent to an exact type match. When the opcintype is polymorphic, require that the old and new foreign types match exactly. (Since ri_triggers.c does use the executor, the stronger check for polymorphic types is no mere future-proofing. However, no core type exercises its necessity.) Author: Noah Misch Committer's note: catalog version bumped due to change of the Constraint node. I can't actually find any way to have such a node in a stored rule, but given that we have "out" support for them, better be safe.
2012-02-27 22:28:00 +01:00
*
* A function with a polymorphic argument could change behavior
* arbitrarily in response to get_fn_expr_argtype(). Therefore,
* when the cast destination is polymorphic, we only avoid
* revalidation if the input type has not changed at all. Given
* just the core data types and operator classes, this requirement
* prevents no would-be optimizations.
*
* If the cast converts from a base type to a domain thereon, then
* that domain type must be the opcintype of the unique index.
* Necessarily, the primary key column must then be of the domain
* type. Since the constraint was previously valid, all values on
* the foreign side necessarily exist on the primary side and in
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* turn conform to the domain. Consequently, we need not treat
ALTER TABLE: skip FK validation when it's safe to do so We already skip rewriting the table in these cases, but we still force a whole table scan to validate the data. This can be skipped, and thus we can make the whole ALTER TABLE operation just do some catalog touches instead of scanning the table, when these two conditions hold: (a) Old and new pg_constraint.conpfeqop match exactly. This is actually stronger than needed; we could loosen things by way of operator families, but it'd require a lot more effort. (b) The functions, if any, implementing a cast from the foreign type to the primary opcintype are the same. For this purpose, we can consider a binary coercion equivalent to an exact type match. When the opcintype is polymorphic, require that the old and new foreign types match exactly. (Since ri_triggers.c does use the executor, the stronger check for polymorphic types is no mere future-proofing. However, no core type exercises its necessity.) Author: Noah Misch Committer's note: catalog version bumped due to change of the Constraint node. I can't actually find any way to have such a node in a stored rule, but given that we have "out" support for them, better be safe.
2012-02-27 22:28:00 +01:00
* domains specially here.
*
* Since we require that all collations share the same notion of
* equality (which they do, because texteq reduces to bitwise
* equality), we don't compare collation here.
*
* We need not directly consider the PK type. It's necessarily
* binary coercible to the opcintype of the unique index column,
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* and ri_triggers.c will only deal with PK datums in terms of
* that opcintype. Changing the opcintype also changes pfeqop.
ALTER TABLE: skip FK validation when it's safe to do so We already skip rewriting the table in these cases, but we still force a whole table scan to validate the data. This can be skipped, and thus we can make the whole ALTER TABLE operation just do some catalog touches instead of scanning the table, when these two conditions hold: (a) Old and new pg_constraint.conpfeqop match exactly. This is actually stronger than needed; we could loosen things by way of operator families, but it'd require a lot more effort. (b) The functions, if any, implementing a cast from the foreign type to the primary opcintype are the same. For this purpose, we can consider a binary coercion equivalent to an exact type match. When the opcintype is polymorphic, require that the old and new foreign types match exactly. (Since ri_triggers.c does use the executor, the stronger check for polymorphic types is no mere future-proofing. However, no core type exercises its necessity.) Author: Noah Misch Committer's note: catalog version bumped due to change of the Constraint node. I can't actually find any way to have such a node in a stored rule, but given that we have "out" support for them, better be safe.
2012-02-27 22:28:00 +01:00
*/
old_check_ok = (new_pathtype == old_pathtype &&
new_castfunc == old_castfunc &&
(!IsPolymorphicType(pfeqop_right) ||
new_fktype == old_fktype));
}
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
pfeqoperators[i] = pfeqop;
ppeqoperators[i] = ppeqop;
ffeqoperators[i] = ffeqop;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
/*
* Record the FK constraint in pg_constraint.
*/
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
constrOid = CreateConstraintEntry(fkconstraint->conname,
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
RelationGetNamespace(rel),
CONSTRAINT_FOREIGN,
fkconstraint->deferrable,
fkconstraint->initdeferred,
Make FKs valid at creation when added as column constraints. Bug report from Alvaro Herrera
2011-03-23 00:10:35 +01:00
fkconstraint->initially_valid,
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
RelationGetRelid(rel),
fkattnum,
numfks,
pgindent run.
2003-08-04 02:43:34 +02:00
InvalidOid, /* not a domain
* constraint */
Add system catalog columns pg_constraint.conindid and pg_trigger.tgconstrindid. conindid is the index supporting a constraint. We can use this not only for unique/primary-key constraints, but also foreign-key constraints, which depend on the unique index that constrains the referenced columns. tgconstrindid is just copied from the constraint's conindid field, or is zero for triggers not associated with constraints. This is mainly intended as infrastructure for upcoming patches, but it has some virtue in itself, since it exposes a relationship that you formerly had to grovel in pg_depend to determine. I simplified one information_schema view accordingly. (There is a pg_dump query that could also use conindid, but I left it alone because it wasn't clear it'd get any faster.)
2009-07-28 04:56:31 +02:00
indexOid,
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
RelationGetRelid(pkrel),
pkattnum,
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
pfeqoperators,
ppeqoperators,
ffeqoperators,
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
numpks,
fkconstraint->fk_upd_action,
fkconstraint->fk_del_action,
fkconstraint->fk_matchtype,
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
NULL, /* no exclusion constraint */
pgindent run.
2003-08-04 02:43:34 +02:00
NULL, /* no check constraint */
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
NULL,
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
NULL,
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
true, /* islocal */
Allow CHECK constraints to be declared ONLY This makes them enforceable only on the parent table, not on children tables. This is useful in various situations, per discussion involving people bitten by the restrictive behavior introduced in 8.4. Message-Id: 8762mp93iw.fsf@comcast.net CAFaPBrSMMpubkGf4zcRL_YL-AERUbYF_-ZNNYfb3CVwwEqc9TQ@mail.gmail.com Authors: Nikhil Sontakke, Alex Hunsaker Reviewed by Robert Haas and myself
2011-12-05 19:10:18 +01:00
0, /* inhcount */
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
true, /* isnoinherit */
false); /* is_internal */
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
/*
* Create the triggers that will enforce the constraint.
*/
Add system catalog columns pg_constraint.conindid and pg_trigger.tgconstrindid. conindid is the index supporting a constraint. We can use this not only for unique/primary-key constraints, but also foreign-key constraints, which depend on the unique index that constrains the referenced columns. tgconstrindid is just copied from the constraint's conindid field, or is zero for triggers not associated with constraints. This is mainly intended as infrastructure for upcoming patches, but it has some virtue in itself, since it exposes a relationship that you formerly had to grovel in pg_depend to determine. I simplified one information_schema view accordingly. (There is a pg_dump query that could also use conindid, but I left it alone because it wasn't clear it'd get any faster.)
2009-07-28 04:56:31 +02:00
createForeignKeyTriggers(rel, fkconstraint, constrOid, indexOid);
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
/*
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* Tell Phase 3 to check that the constraint is satisfied by existing
* rows. We can skip this during table creation, when requested explicitly
* by specifying NOT VALID in an ADD FOREIGN KEY command, and when we're
* recreating a constraint following a SET DATA TYPE operation that did
* not impugn its validity.
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
*/
ALTER TABLE: skip FK validation when it's safe to do so We already skip rewriting the table in these cases, but we still force a whole table scan to validate the data. This can be skipped, and thus we can make the whole ALTER TABLE operation just do some catalog touches instead of scanning the table, when these two conditions hold: (a) Old and new pg_constraint.conpfeqop match exactly. This is actually stronger than needed; we could loosen things by way of operator families, but it'd require a lot more effort. (b) The functions, if any, implementing a cast from the foreign type to the primary opcintype are the same. For this purpose, we can consider a binary coercion equivalent to an exact type match. When the opcintype is polymorphic, require that the old and new foreign types match exactly. (Since ri_triggers.c does use the executor, the stronger check for polymorphic types is no mere future-proofing. However, no core type exercises its necessity.) Author: Noah Misch Committer's note: catalog version bumped due to change of the Constraint node. I can't actually find any way to have such a node in a stored rule, but given that we have "out" support for them, better be safe.
2012-02-27 22:28:00 +01:00
if (!old_check_ok && !fkconstraint->skip_validation)
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
{
NewConstraint *newcon;
newcon = (NewConstraint *) palloc0(sizeof(NewConstraint));
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
newcon->name = fkconstraint->conname;
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
newcon->contype = CONSTR_FOREIGN;
newcon->refrelid = RelationGetRelid(pkrel);
Add system catalog columns pg_constraint.conindid and pg_trigger.tgconstrindid. conindid is the index supporting a constraint. We can use this not only for unique/primary-key constraints, but also foreign-key constraints, which depend on the unique index that constrains the referenced columns. tgconstrindid is just copied from the constraint's conindid field, or is zero for triggers not associated with constraints. This is mainly intended as infrastructure for upcoming patches, but it has some virtue in itself, since it exposes a relationship that you formerly had to grovel in pg_depend to determine. I simplified one information_schema view accordingly. (There is a pg_dump query that could also use conindid, but I left it alone because it wasn't clear it'd get any faster.)
2009-07-28 04:56:31 +02:00
newcon->refindid = indexOid;
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
newcon->conid = constrOid;
newcon->qual = (Node *) fkconstraint;
tab->constraints = lappend(tab->constraints, newcon);
}
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
/*
* Close pk table, but keep lock until we've committed.
*/
heap_close(pkrel, NoLock);
}
Extend ALTER TABLE to allow Foreign Keys to be added without initial validation. 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
2011-02-08 13:23:20 +01:00
/*
* ALTER TABLE VALIDATE CONSTRAINT
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
*
* XXX The reason we handle recursion here rather than at Phase 1 is because
* there's no good way to skip recursing when handling foreign keys: there is
* no need to lock children in that case, yet we wouldn't be able to avoid
* doing so at that level.
Extend ALTER TABLE to allow Foreign Keys to be added without initial validation. 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
2011-02-08 13:23:20 +01:00
*/
static void
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
ATExecValidateConstraint(Relation rel, char *constrName, bool recurse,
bool recursing, LOCKMODE lockmode)
Extend ALTER TABLE to allow Foreign Keys to be added without initial validation. 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
2011-02-08 13:23:20 +01:00
{
Relation conrel;
SysScanDesc scan;
ScanKeyData key;
HeapTuple tuple;
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.
2011-02-09 00:12:17 +01:00
Form_pg_constraint con = NULL;
Extend ALTER TABLE to allow Foreign Keys to be added without initial validation. 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
2011-02-08 13:23:20 +01:00
bool found = false;
conrel = heap_open(ConstraintRelationId, RowExclusiveLock);
/*
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.
2011-02-09 00:12:17 +01:00
* Find and check the target constraint
Extend ALTER TABLE to allow Foreign Keys to be added without initial validation. 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
2011-02-08 13:23:20 +01:00
*/
ScanKeyInit(&key,
Anum_pg_constraint_conrelid,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(RelationGetRelid(rel)));
scan = systable_beginscan(conrel, ConstraintRelidIndexId,
true, SnapshotNow, 1, &key);
while (HeapTupleIsValid(tuple = systable_getnext(scan)))
{
con = (Form_pg_constraint) GETSTRUCT(tuple);
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
if (strcmp(NameStr(con->conname), constrName) == 0)
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.
2011-02-09 00:12:17 +01:00
{
found = true;
break;
}
Extend ALTER TABLE to allow Foreign Keys to be added without initial validation. 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
2011-02-08 13:23:20 +01:00
}
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.
2011-02-09 00:12:17 +01:00
if (!found)
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_OBJECT),
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
errmsg("constraint \"%s\" of relation \"%s\" does not exist",
constrName, RelationGetRelationName(rel))));
if (con->contype != CONSTRAINT_FOREIGN &&
con->contype != CONSTRAINT_CHECK)
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("constraint \"%s\" of relation \"%s\" is not a foreign key or check constraint",
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
constrName, RelationGetRelationName(rel))));
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.
2011-02-09 00:12:17 +01:00
if (!con->convalidated)
Extend ALTER TABLE to allow Foreign Keys to be added without initial validation. 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
2011-02-08 13:23:20 +01:00
{
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
HeapTuple copyTuple;
Form_pg_constraint copy_con;
Extend ALTER TABLE to allow Foreign Keys to be added without initial validation. 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
2011-02-08 13:23:20 +01:00
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
if (con->contype == CONSTRAINT_FOREIGN)
{
Oid conid = HeapTupleGetOid(tuple);
Relation refrel;
/*
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* Triggers are already in place on both tables, so a concurrent
* write that alters the result here is not possible. Normally we
* can run a query here to do the validation, which would only
* require AccessShareLock. In some cases, it is possible that we
* might need to fire triggers to perform the check, so we take a
* lock at RowShareLock level just in case.
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
*/
refrel = heap_open(con->confrelid, RowShareLock);
validateForeignKeyConstraint(constrName, rel, refrel,
con->conindid,
conid);
heap_close(refrel, NoLock);
/*
Lots of doc corrections. Josh Kupershmidt
2012-04-24 04:43:09 +02:00
* Foreign keys do not inherit, so we purposely ignore the
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
* recursion bit here
*/
}
else if (con->contype == CONSTRAINT_CHECK)
{
List *children = NIL;
ListCell *child;
/*
* If we're recursing, the parent has already done this, so skip
* it.
*/
if (!recursing)
children = find_all_inheritors(RelationGetRelid(rel),
lockmode, NULL);
/*
* For CHECK constraints, we must ensure that we only mark the
* constraint as validated on the parent if it's already validated
* on the children.
*
* We recurse before validating on the parent, to reduce risk of
* deadlocks.
*/
foreach(child, children)
{
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
Oid childoid = lfirst_oid(child);
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
Relation childrel;
Extend ALTER TABLE to allow Foreign Keys to be added without initial validation. 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
2011-02-08 13:23:20 +01:00
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
if (childoid == RelationGetRelid(rel))
continue;
/*
* If we are told not to recurse, there had better not be any
* child tables; else the addition would put them out of step.
*/
if (!recurse)
ereport(ERROR,
(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
errmsg("constraint must be validated on child tables too")));
/* find_all_inheritors already got lock */
childrel = heap_open(childoid, NoLock);
ATExecValidateConstraint(childrel, constrName, false,
true, lockmode);
heap_close(childrel, NoLock);
}
validateCheckConstraint(rel, tuple);
/*
* Invalidate relcache so that others see the new validated
* constraint.
*/
CacheInvalidateRelcache(rel);
}
Extend ALTER TABLE to allow Foreign Keys to be added without initial validation. 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
2011-02-08 13:23:20 +01:00
/*
* Now update the catalog, while we have the door open.
*/
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
copyTuple = heap_copytuple(tuple);
copy_con = (Form_pg_constraint) GETSTRUCT(copyTuple);
Extend ALTER TABLE to allow Foreign Keys to be added without initial validation. 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
2011-02-08 13:23:20 +01:00
copy_con->convalidated = true;
simple_heap_update(conrel, &copyTuple->t_self, copyTuple);
CatalogUpdateIndexes(conrel, copyTuple);
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
InvokeObjectPostAlterHook(ConstraintRelationId,
HeapTupleGetOid(tuple), 0);
Extend ALTER TABLE to allow Foreign Keys to be added without initial validation. 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
2011-02-08 13:23:20 +01:00
heap_freetuple(copyTuple);
}
systable_endscan(scan);
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.
2011-02-09 00:12:17 +01:00
heap_close(conrel, RowExclusiveLock);
Extend ALTER TABLE to allow Foreign Keys to be added without initial validation. 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
2011-02-08 13:23:20 +01:00
}
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
Rework parsing of ConstraintAttributeSpec to improve NOT VALID handling. 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.
2011-06-16 01:05:11 +02:00
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
/*
* transformColumnNameList - transform list of column names
*
* Lookup each name and return its attnum and type OID
*/
static int
transformColumnNameList(Oid relId, List *colList,
int16 *attnums, Oid *atttypids)
{
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *l;
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
int attnum;
attnum = 0;
foreach(l, colList)
{
char *attname = strVal(lfirst(l));
HeapTuple atttuple;
atttuple = SearchSysCacheAttName(relId, attname);
if (!HeapTupleIsValid(atttuple))
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_COLUMN),
errmsg("column \"%s\" referenced in foreign key constraint does not exist",
attname)));
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
if (attnum >= INDEX_MAX_KEYS)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_TOO_MANY_COLUMNS),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("cannot have more than %d keys in a foreign key",
INDEX_MAX_KEYS)));
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
attnums[attnum] = ((Form_pg_attribute) GETSTRUCT(atttuple))->attnum;
atttypids[attnum] = ((Form_pg_attribute) GETSTRUCT(atttuple))->atttypid;
ReleaseSysCache(atttuple);
attnum++;
}
return attnum;
}
/*
* transformFkeyGetPrimaryKey -
*
* Look up the names, attnums, and types of the primary key attributes
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
* for the pkrel. Also return the index OID and index opclasses of the
Generate a WARNING when the column types in a foreign key constraint are incompatible enough to prevent indexscanning the referenced table. Also, improve the error message that pops out when we can't implement the FK at all for lack of a usable equality operator. Fabien Coelho, with some review by Tom Lane.
2004-03-13 23:09:14 +01:00
* index supporting the primary key.
*
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
* All parameters except pkrel are output parameters. Also, the function
Generate a WARNING when the column types in a foreign key constraint are incompatible enough to prevent indexscanning the referenced table. Also, improve the error message that pops out when we can't implement the FK at all for lack of a usable equality operator. Fabien Coelho, with some review by Tom Lane.
2004-03-13 23:09:14 +01:00
* return value is the number of attributes in the primary key.
*
* Used when the column list in the REFERENCES specification is omitted.
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
*/
static int
transformFkeyGetPrimaryKey(Relation pkrel, Oid *indexOid,
List **attnamelist,
Generate a WARNING when the column types in a foreign key constraint are incompatible enough to prevent indexscanning the referenced table. Also, improve the error message that pops out when we can't implement the FK at all for lack of a usable equality operator. Fabien Coelho, with some review by Tom Lane.
2004-03-13 23:09:14 +01:00
int16 *attnums, Oid *atttypids,
Oid *opclasses)
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
{
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
List *indexoidlist;
ListCell *indexoidscan;
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
HeapTuple indexTuple = NULL;
Form_pg_index indexStruct = NULL;
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
Datum indclassDatum;
bool isnull;
oidvector *indclass;
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
int i;
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Get the list of index OIDs for the table from the relcache, and look up
* each one in the pg_index syscache until we find one marked primary key
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY. Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor choice of catalog state representation. The pg_index state for an index that's reached the final pre-drop stage was the same as the state for an index just created by CREATE INDEX CONCURRENTLY. This meant that the (necessary) change to make RelationGetIndexList ignore about-to-die indexes also made it ignore freshly-created indexes; which is catastrophic because the latter do need to be considered in HOT-safety decisions. Failure to do so leads to incorrect index entries and subsequently wrong results from queries depending on the concurrently-created index. To fix, add an additional boolean column "indislive" to pg_index, so that the freshly-created and about-to-die states can be distinguished. (This change obviously is only possible in HEAD. This patch will need to be back-patched, but in 9.2 we'll use a kluge consisting of overloading the formerly-impossible state of indisvalid = true and indisready = false.) In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index flag changes they make without exclusive lock on the index are made via heap_inplace_update() rather than a normal transactional update. The latter is not very safe because moving the pg_index tuple could result in concurrent SnapshotNow scans finding it twice or not at all, thus possibly resulting in index corruption. This is a pre-existing bug in CREATE INDEX CONCURRENTLY, which was copied into the DROP code. In addition, fix various places in the code that ought to check to make sure that the indexes they are manipulating are valid and/or ready as appropriate. These represent bugs that have existed since 8.2, since a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid index behind, and we ought not try to do anything that might fail with such an index. Also fix RelationReloadIndexInfo to ensure it copies all the pg_index columns that are allowed to change after initial creation. Previously we could have been left with stale values of some fields in an index relcache entry. It's not clear whether this actually had any user-visible consequences, but it's at least a bug waiting to happen. In addition, do some code and docs review for DROP INDEX CONCURRENTLY; some cosmetic code cleanup but mostly addition and revision of comments. This will need to be back-patched, but in a noticeably different form, so I'm committing it to HEAD before working on the back-patch. Problem reported by Amit Kapila, diagnosis by Pavan Deolassee, fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
* (hopefully there isn't more than one such). Insist it's valid, too.
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
*/
Clean up possibly-uninitialized-variable warnings reported by gcc 4.x.
2005-09-25 00:54:44 +02:00
*indexOid = InvalidOid;
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
indexoidlist = RelationGetIndexList(pkrel);
foreach(indexoidscan, indexoidlist)
{
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
Oid indexoid = lfirst_oid(indexoidscan);
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
Wrap calls to SearchSysCache and related functions using macros. The purpose of this change is to eliminate the need for every caller of SearchSysCache, SearchSysCacheCopy, SearchSysCacheExists, GetSysCacheOid, and SearchSysCacheList to know the maximum number of allowable keys for a syscache entry (currently 4). This will make it far easier to increase the maximum number of keys in a future release should we choose to do so, and it makes the code shorter, too. Design and review by Tom Lane.
2010-02-14 19:42:19 +01:00
indexTuple = SearchSysCache1(INDEXRELID, ObjectIdGetDatum(indexoid));
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
if (!HeapTupleIsValid(indexTuple))
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
elog(ERROR, "cache lookup failed for index %u", indexoid);
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
indexStruct = (Form_pg_index) GETSTRUCT(indexTuple);
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY. Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor choice of catalog state representation. The pg_index state for an index that's reached the final pre-drop stage was the same as the state for an index just created by CREATE INDEX CONCURRENTLY. This meant that the (necessary) change to make RelationGetIndexList ignore about-to-die indexes also made it ignore freshly-created indexes; which is catastrophic because the latter do need to be considered in HOT-safety decisions. Failure to do so leads to incorrect index entries and subsequently wrong results from queries depending on the concurrently-created index. To fix, add an additional boolean column "indislive" to pg_index, so that the freshly-created and about-to-die states can be distinguished. (This change obviously is only possible in HEAD. This patch will need to be back-patched, but in 9.2 we'll use a kluge consisting of overloading the formerly-impossible state of indisvalid = true and indisready = false.) In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index flag changes they make without exclusive lock on the index are made via heap_inplace_update() rather than a normal transactional update. The latter is not very safe because moving the pg_index tuple could result in concurrent SnapshotNow scans finding it twice or not at all, thus possibly resulting in index corruption. This is a pre-existing bug in CREATE INDEX CONCURRENTLY, which was copied into the DROP code. In addition, fix various places in the code that ought to check to make sure that the indexes they are manipulating are valid and/or ready as appropriate. These represent bugs that have existed since 8.2, since a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid index behind, and we ought not try to do anything that might fail with such an index. Also fix RelationReloadIndexInfo to ensure it copies all the pg_index columns that are allowed to change after initial creation. Previously we could have been left with stale values of some fields in an index relcache entry. It's not clear whether this actually had any user-visible consequences, but it's at least a bug waiting to happen. In addition, do some code and docs review for DROP INDEX CONCURRENTLY; some cosmetic code cleanup but mostly addition and revision of comments. This will need to be back-patched, but in a noticeably different form, so I'm committing it to HEAD before working on the back-patch. Problem reported by Amit Kapila, diagnosis by Pavan Deolassee, fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
if (indexStruct->indisprimary && IndexIsValid(indexStruct))
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
{
Support deferrable uniqueness constraints. The current implementation fires an AFTER ROW trigger for each tuple that looks like it might be non-unique according to the index contents at the time of insertion. This works well as long as there aren't many conflicts, but won't scale to massive unique-key reassignments. Improving that case is a TODO item. Dean Rasheed
2009-07-29 22:56:21 +02:00
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* Refuse to use a deferrable primary key. This is per SQL spec,
* and there would be a lot of interesting semantic problems if we
* tried to allow it.
Support deferrable uniqueness constraints. The current implementation fires an AFTER ROW trigger for each tuple that looks like it might be non-unique according to the index contents at the time of insertion. This works well as long as there aren't many conflicts, but won't scale to massive unique-key reassignments. Improving that case is a TODO item. Dean Rasheed
2009-07-29 22:56:21 +02:00
*/
if (!indexStruct->indimmediate)
ereport(ERROR,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("cannot use a deferrable primary key for referenced table \"%s\"",
RelationGetRelationName(pkrel))));
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
*indexOid = indexoid;
break;
}
ReleaseSysCache(indexTuple);
}
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
list_free(indexoidlist);
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
/*
* Check that we found it
*/
Clean up possibly-uninitialized-variable warnings reported by gcc 4.x.
2005-09-25 00:54:44 +02:00
if (!OidIsValid(*indexOid))
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_OBJECT),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("there is no primary key for referenced table \"%s\"",
RelationGetRelationName(pkrel))));
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
/* Must get indclass the hard way */
indclassDatum = SysCacheGetAttr(INDEXRELID, indexTuple,
Anum_pg_index_indclass, &isnull);
Assert(!isnull);
indclass = (oidvector *) DatumGetPointer(indclassDatum);
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
/*
pgindent run.
2003-08-04 02:43:34 +02:00
* Now build the list of PK attributes from the indkey definition (we
* assume a primary key cannot have expressional elements)
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
*/
*attnamelist = NIL;
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
for (i = 0; i < indexStruct->indnatts; i++)
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
{
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
int pkattno = indexStruct->indkey.values[i];
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
attnums[i] = pkattno;
atttypids[i] = attnumTypeId(pkrel, pkattno);
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
opclasses[i] = indclass->values[i];
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
*attnamelist = lappend(*attnamelist,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
makeString(pstrdup(NameStr(*attnumAttName(pkrel, pkattno)))));
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
}
ReleaseSysCache(indexTuple);
return i;
}
/*
* transformFkeyCheckAttrs -
*
* Make sure that the attributes of a referenced table belong to a unique
* (or primary key) constraint. Return the OID of the index supporting
Generate a WARNING when the column types in a foreign key constraint are incompatible enough to prevent indexscanning the referenced table. Also, improve the error message that pops out when we can't implement the FK at all for lack of a usable equality operator. Fabien Coelho, with some review by Tom Lane.
2004-03-13 23:09:14 +01:00
* the constraint, as well as the opclasses associated with the index
* columns.
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
*/
static Oid
transformFkeyCheckAttrs(Relation pkrel,
Generate a WARNING when the column types in a foreign key constraint are incompatible enough to prevent indexscanning the referenced table. Also, improve the error message that pops out when we can't implement the FK at all for lack of a usable equality operator. Fabien Coelho, with some review by Tom Lane.
2004-03-13 23:09:14 +01:00
int numattrs, int16 *attnums,
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
Oid *opclasses) /* output parameter */
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
{
Oid indexoid = InvalidOid;
bool found = false;
Improve error message for the case where a requested foreign key constraint does match some unique index on the referenced table, but that index is only deferrably unique. We were doing this nicely for the default-to-primary-key case, but were being lazy for the other case. Dean Rasheed
2009-08-13 01:00:12 +02:00
bool found_deferrable = false;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
List *indexoidlist;
ListCell *indexoidscan;
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Get the list of index OIDs for the table from the relcache, and look up
* each one in the pg_index syscache, and match unique indexes to the list
* of attnums we are given.
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
*/
indexoidlist = RelationGetIndexList(pkrel);
foreach(indexoidscan, indexoidlist)
{
HeapTuple indexTuple;
Form_pg_index indexStruct;
pgindent run.
2003-08-04 02:43:34 +02:00
int i,
j;
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
indexoid = lfirst_oid(indexoidscan);
Wrap calls to SearchSysCache and related functions using macros. The purpose of this change is to eliminate the need for every caller of SearchSysCache, SearchSysCacheCopy, SearchSysCacheExists, GetSysCacheOid, and SearchSysCacheList to know the maximum number of allowable keys for a syscache entry (currently 4). This will make it far easier to increase the maximum number of keys in a future release should we choose to do so, and it makes the code shorter, too. Design and review by Tom Lane.
2010-02-14 19:42:19 +01:00
indexTuple = SearchSysCache1(INDEXRELID, ObjectIdGetDatum(indexoid));
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
if (!HeapTupleIsValid(indexTuple))
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
elog(ERROR, "cache lookup failed for index %u", indexoid);
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
indexStruct = (Form_pg_index) GETSTRUCT(indexTuple);
/*
Improve error message for the case where a requested foreign key constraint does match some unique index on the referenced table, but that index is only deferrably unique. We were doing this nicely for the default-to-primary-key case, but were being lazy for the other case. Dean Rasheed
2009-08-13 01:00:12 +02:00
* Must have the right number of columns; must be unique and not a
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY. Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor choice of catalog state representation. The pg_index state for an index that's reached the final pre-drop stage was the same as the state for an index just created by CREATE INDEX CONCURRENTLY. This meant that the (necessary) change to make RelationGetIndexList ignore about-to-die indexes also made it ignore freshly-created indexes; which is catastrophic because the latter do need to be considered in HOT-safety decisions. Failure to do so leads to incorrect index entries and subsequently wrong results from queries depending on the concurrently-created index. To fix, add an additional boolean column "indislive" to pg_index, so that the freshly-created and about-to-die states can be distinguished. (This change obviously is only possible in HEAD. This patch will need to be back-patched, but in 9.2 we'll use a kluge consisting of overloading the formerly-impossible state of indisvalid = true and indisready = false.) In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index flag changes they make without exclusive lock on the index are made via heap_inplace_update() rather than a normal transactional update. The latter is not very safe because moving the pg_index tuple could result in concurrent SnapshotNow scans finding it twice or not at all, thus possibly resulting in index corruption. This is a pre-existing bug in CREATE INDEX CONCURRENTLY, which was copied into the DROP code. In addition, fix various places in the code that ought to check to make sure that the indexes they are manipulating are valid and/or ready as appropriate. These represent bugs that have existed since 8.2, since a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid index behind, and we ought not try to do anything that might fail with such an index. Also fix RelationReloadIndexInfo to ensure it copies all the pg_index columns that are allowed to change after initial creation. Previously we could have been left with stale values of some fields in an index relcache entry. It's not clear whether this actually had any user-visible consequences, but it's at least a bug waiting to happen. In addition, do some code and docs review for DROP INDEX CONCURRENTLY; some cosmetic code cleanup but mostly addition and revision of comments. This will need to be back-patched, but in a noticeably different form, so I'm committing it to HEAD before working on the back-patch. Problem reported by Amit Kapila, diagnosis by Pavan Deolassee, fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
* partial index; forget it if there are any expressions, too. Invalid
* indexes are out as well.
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
*/
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
if (indexStruct->indnatts == numattrs &&
Improve error message for the case where a requested foreign key constraint does match some unique index on the referenced table, but that index is only deferrably unique. We were doing this nicely for the default-to-primary-key case, but were being lazy for the other case. Dean Rasheed
2009-08-13 01:00:12 +02:00
indexStruct->indisunique &&
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY. Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor choice of catalog state representation. The pg_index state for an index that's reached the final pre-drop stage was the same as the state for an index just created by CREATE INDEX CONCURRENTLY. This meant that the (necessary) change to make RelationGetIndexList ignore about-to-die indexes also made it ignore freshly-created indexes; which is catastrophic because the latter do need to be considered in HOT-safety decisions. Failure to do so leads to incorrect index entries and subsequently wrong results from queries depending on the concurrently-created index. To fix, add an additional boolean column "indislive" to pg_index, so that the freshly-created and about-to-die states can be distinguished. (This change obviously is only possible in HEAD. This patch will need to be back-patched, but in 9.2 we'll use a kluge consisting of overloading the formerly-impossible state of indisvalid = true and indisready = false.) In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index flag changes they make without exclusive lock on the index are made via heap_inplace_update() rather than a normal transactional update. The latter is not very safe because moving the pg_index tuple could result in concurrent SnapshotNow scans finding it twice or not at all, thus possibly resulting in index corruption. This is a pre-existing bug in CREATE INDEX CONCURRENTLY, which was copied into the DROP code. In addition, fix various places in the code that ought to check to make sure that the indexes they are manipulating are valid and/or ready as appropriate. These represent bugs that have existed since 8.2, since a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid index behind, and we ought not try to do anything that might fail with such an index. Also fix RelationReloadIndexInfo to ensure it copies all the pg_index columns that are allowed to change after initial creation. Previously we could have been left with stale values of some fields in an index relcache entry. It's not clear whether this actually had any user-visible consequences, but it's at least a bug waiting to happen. In addition, do some code and docs review for DROP INDEX CONCURRENTLY; some cosmetic code cleanup but mostly addition and revision of comments. This will need to be back-patched, but in a noticeably different form, so I'm committing it to HEAD before working on the back-patch. Problem reported by Amit Kapila, diagnosis by Pavan Deolassee, fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
IndexIsValid(indexStruct) &&
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
heap_attisnull(indexTuple, Anum_pg_index_indpred) &&
heap_attisnull(indexTuple, Anum_pg_index_indexprs))
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
{
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
/* Must get indclass the hard way */
Datum indclassDatum;
bool isnull;
oidvector *indclass;
indclassDatum = SysCacheGetAttr(INDEXRELID, indexTuple,
Anum_pg_index_indclass, &isnull);
Assert(!isnull);
indclass = (oidvector *) DatumGetPointer(indclassDatum);
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* The given attnum list may match the index columns in any order.
* Check that each list is a subset of the other.
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
*/
for (i = 0; i < numattrs; i++)
{
found = false;
for (j = 0; j < numattrs; j++)
{
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
if (attnums[i] == indexStruct->indkey.values[j])
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
{
found = true;
break;
}
}
if (!found)
break;
}
if (found)
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
{
for (i = 0; i < numattrs; i++)
{
found = false;
for (j = 0; j < numattrs; j++)
{
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
if (attnums[j] == indexStruct->indkey.values[i])
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
{
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
opclasses[j] = indclass->values[i];
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
found = true;
break;
}
}
if (!found)
break;
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
}
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
}
Improve error message for the case where a requested foreign key constraint does match some unique index on the referenced table, but that index is only deferrably unique. We were doing this nicely for the default-to-primary-key case, but were being lazy for the other case. Dean Rasheed
2009-08-13 01:00:12 +02:00
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* Refuse to use a deferrable unique/primary key. This is per SQL
* spec, and there would be a lot of interesting semantic problems
* if we tried to allow it.
Improve error message for the case where a requested foreign key constraint does match some unique index on the referenced table, but that index is only deferrably unique. We were doing this nicely for the default-to-primary-key case, but were being lazy for the other case. Dean Rasheed
2009-08-13 01:00:12 +02:00
*/
if (found && !indexStruct->indimmediate)
{
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* Remember that we found an otherwise matching index, so that
* we can generate a more appropriate error message.
Improve error message for the case where a requested foreign key constraint does match some unique index on the referenced table, but that index is only deferrably unique. We were doing this nicely for the default-to-primary-key case, but were being lazy for the other case. Dean Rasheed
2009-08-13 01:00:12 +02:00
*/
found_deferrable = true;
found = false;
}
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
}
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
ReleaseSysCache(indexTuple);
if (found)
break;
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
}
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
if (!found)
Improve error message for the case where a requested foreign key constraint does match some unique index on the referenced table, but that index is only deferrably unique. We were doing this nicely for the default-to-primary-key case, but were being lazy for the other case. Dean Rasheed
2009-08-13 01:00:12 +02:00
{
if (found_deferrable)
ereport(ERROR,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("cannot use a deferrable unique constraint for referenced table \"%s\"",
RelationGetRelationName(pkrel))));
else
ereport(ERROR,
(errcode(ERRCODE_INVALID_FOREIGN_KEY),
errmsg("there is no unique constraint matching given keys for referenced table \"%s\"",
RelationGetRelationName(pkrel))));
}
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
list_free(indexoidlist);
Move most of the error checking for foreign-key constraints out of parse analysis and into the execution code (in tablecmds.c). This eliminates a lot of unreasonably complex code that needed to have two or more execution paths in case it was dealing with a not-yet-created table column vs. an already-existing one. The execution code is always dealing with already-created tables and so needs only one case. This also eliminates some potential race conditions (the table wasn't locked between parse analysis and execution), makes it easy to fix the gripe about wrong referenced-column names generating a misleading error message, and lets us easily add a dependency from the foreign-key constraint to the unique index that it requires the referenced table to have. (Cf. complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.) Also, third try at building a deletion mechanism that is not sensitive to the order in which pg_depend entries are visited. Adding the above- mentioned dependency exposed the folly of what dependency.c had been doing: it failed for cases where B depends on C while both auto-depend on A. Dropping A should succeed in this case, but was failing if C happened to be visited before B. It appears the only solution is two separate walks over the dependency tree.
2002-09-22 02:37:09 +02:00
return indexoid;
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
}
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
ALTER TABLE: skip FK validation when it's safe to do so We already skip rewriting the table in these cases, but we still force a whole table scan to validate the data. This can be skipped, and thus we can make the whole ALTER TABLE operation just do some catalog touches instead of scanning the table, when these two conditions hold: (a) Old and new pg_constraint.conpfeqop match exactly. This is actually stronger than needed; we could loosen things by way of operator families, but it'd require a lot more effort. (b) The functions, if any, implementing a cast from the foreign type to the primary opcintype are the same. For this purpose, we can consider a binary coercion equivalent to an exact type match. When the opcintype is polymorphic, require that the old and new foreign types match exactly. (Since ri_triggers.c does use the executor, the stronger check for polymorphic types is no mere future-proofing. However, no core type exercises its necessity.) Author: Noah Misch Committer's note: catalog version bumped due to change of the Constraint node. I can't actually find any way to have such a node in a stored rule, but given that we have "out" support for them, better be safe.
2012-02-27 22:28:00 +01:00
/*
* findFkeyCast -
*
* Wrapper around find_coercion_pathway() for ATAddForeignKeyConstraint().
* Caller has equal regard for binary coercibility and for an exact match.
*/
static CoercionPathType
findFkeyCast(Oid targetTypeId, Oid sourceTypeId, Oid *funcid)
{
CoercionPathType ret;
if (targetTypeId == sourceTypeId)
{
ret = COERCION_PATH_RELABELTYPE;
*funcid = InvalidOid;
}
else
{
ret = find_coercion_pathway(targetTypeId, sourceTypeId,
COERCION_IMPLICIT, funcid);
if (ret == COERCION_PATH_NONE)
/* A previously-relied-upon cast is now gone. */
elog(ERROR, "could not find cast from %u to %u",
sourceTypeId, targetTypeId);
}
return ret;
}
Support column-level privileges, as required by SQL standard. Stephen Frost, with help from KaiGai Kohei and others
2009-01-22 21:16:10 +01:00
/* Permissions checks for ADD FOREIGN KEY */
static void
checkFkeyPermissions(Relation rel, int16 *attnums, int natts)
{
Oid roleid = GetUserId();
AclResult aclresult;
int i;
/* Okay if we have relation-level REFERENCES permission */
aclresult = pg_class_aclcheck(RelationGetRelid(rel), roleid,
ACL_REFERENCES);
if (aclresult == ACLCHECK_OK)
return;
/* Else we must have REFERENCES on each column */
for (i = 0; i < natts; i++)
{
aclresult = pg_attribute_aclcheck(RelationGetRelid(rel), attnums[i],
roleid, ACL_REFERENCES);
if (aclresult != ACLCHECK_OK)
aclcheck_error(aclresult, ACL_KIND_CLASS,
RelationGetRelationName(rel));
}
}
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
/*
* Scan the existing rows in a table to verify they meet a proposed
* CHECK constraint.
*
* The caller must have opened and locked the relation appropriately.
*/
static void
validateCheckConstraint(Relation rel, HeapTuple constrtup)
{
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
EState *estate;
Datum val;
char *conbin;
Expr *origexpr;
List *exprstate;
TupleDesc tupdesc;
HeapScanDesc scan;
HeapTuple tuple;
ExprContext *econtext;
MemoryContext oldcxt;
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
TupleTableSlot *slot;
Form_pg_constraint constrForm;
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
bool isnull;
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
constrForm = (Form_pg_constraint) GETSTRUCT(constrtup);
estate = CreateExecutorState();
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
/*
* XXX this tuple doesn't really come from a syscache, but this doesn't
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* matter to SysCacheGetAttr, because it only wants to be able to fetch
* the tupdesc
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
*/
val = SysCacheGetAttr(CONSTROID, constrtup, Anum_pg_constraint_conbin,
&isnull);
if (isnull)
elog(ERROR, "null conbin for constraint %u",
HeapTupleGetOid(constrtup));
conbin = TextDatumGetCString(val);
origexpr = (Expr *) stringToNode(conbin);
exprstate = (List *)
ExecPrepareExpr((Expr *) make_ands_implicit(origexpr), estate);
econtext = GetPerTupleExprContext(estate);
tupdesc = RelationGetDescr(rel);
slot = MakeSingleTupleTableSlot(tupdesc);
econtext->ecxt_scantuple = slot;
scan = heap_beginscan(rel, SnapshotNow, 0, NULL);
/*
* Switch to per-tuple memory context and reset it for each tuple
* produced, so we don't leak memory.
*/
oldcxt = MemoryContextSwitchTo(GetPerTupleMemoryContext(estate));
while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
{
ExecStoreTuple(tuple, slot, InvalidBuffer, false);
if (!ExecQual(exprstate, econtext, true))
ereport(ERROR,
(errcode(ERRCODE_CHECK_VIOLATION),
errmsg("check constraint \"%s\" is violated by some row",
Provide database object names as separate fields in error messages. This patch addresses the problem that applications currently have to extract object names from possibly-localized textual error messages, if they want to know for example which index caused a UNIQUE_VIOLATION failure. It adds new error message fields to the wire protocol, which can carry the name of a table, table column, data type, or constraint associated with the error. (Since the protocol spec has always instructed clients to ignore unrecognized field types, this should not create any compatibility problem.) Support for providing these new fields has been added to just a limited set of error reports (mainly, those in the "integrity constraint violation" SQLSTATE class), but we will doubtless add them to more calls in future. Pavel Stehule, reviewed and extensively revised by Peter Geoghegan, with additional hacking by Tom Lane.
2013-01-29 23:06:26 +01:00
NameStr(constrForm->conname)),
errtableconstraint(rel, NameStr(constrForm->conname))));
Enable CHECK constraints to be declared NOT VALID 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.
2011-06-02 00:43:50 +02:00
ResetExprContext(econtext);
}
MemoryContextSwitchTo(oldcxt);
heap_endscan(scan);
ExecDropSingleTupleTableSlot(slot);
FreeExecutorState(estate);
}
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
/*
* Scan the existing rows in a table to verify they meet a proposed FK
* constraint.
*
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
* Caller must have opened and locked both relations appropriately.
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
*/
static void
Extend ALTER TABLE to allow Foreign Keys to be added without initial validation. 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
2011-02-08 13:23:20 +01:00
validateForeignKeyConstraint(char *conname,
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
Relation rel,
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
Relation pkrel,
Add system catalog columns pg_constraint.conindid and pg_trigger.tgconstrindid. conindid is the index supporting a constraint. We can use this not only for unique/primary-key constraints, but also foreign-key constraints, which depend on the unique index that constrains the referenced columns. tgconstrindid is just copied from the constraint's conindid field, or is zero for triggers not associated with constraints. This is mainly intended as infrastructure for upcoming patches, but it has some virtue in itself, since it exposes a relationship that you formerly had to grovel in pg_depend to determine. I simplified one information_schema view accordingly. (There is a pg_dump query that could also use conindid, but I left it alone because it wasn't clear it'd get any faster.)
2009-07-28 04:56:31 +02:00
Oid pkindOid,
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
Oid constraintOid)
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
{
HeapScanDesc scan;
HeapTuple tuple;
Trigger trig;
During ALTER TABLE ADD FOREIGN KEY, try to check the existing rows using a single LEFT JOIN query instead of firing the check trigger for each row individually. Stephan Szabo, with some kibitzing from Tom Lane and Jan Wieck.
2003-10-06 18:38:28 +02:00
Teach ALTER TABLE .. SET DATA TYPE to avoid some table rewrites. 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
2011-02-12 14:27:55 +01:00
ereport(DEBUG1,
(errmsg("validating foreign key constraint \"%s\"", conname)));
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
/*
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
* Build a trigger call structure; we'll need it either way.
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
*/
MemSet(&trig, 0, sizeof(trig));
trig.tgoid = InvalidOid;
Extend ALTER TABLE to allow Foreign Keys to be added without initial validation. 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
2011-02-08 13:23:20 +01:00
trig.tgname = conname;
Changes pg_trigger and extend pg_rewrite in order to allow triggers and 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
2007-03-20 00:38:32 +01:00
trig.tgenabled = TRIGGER_FIRES_ON_ORIGIN;
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
trig.tgisinternal = TRUE;
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
trig.tgconstrrelid = RelationGetRelid(pkrel);
Add system catalog columns pg_constraint.conindid and pg_trigger.tgconstrindid. conindid is the index supporting a constraint. We can use this not only for unique/primary-key constraints, but also foreign-key constraints, which depend on the unique index that constrains the referenced columns. tgconstrindid is just copied from the constraint's conindid field, or is zero for triggers not associated with constraints. This is mainly intended as infrastructure for upcoming patches, but it has some virtue in itself, since it exposes a relationship that you formerly had to grovel in pg_depend to determine. I simplified one information_schema view accordingly. (There is a pg_dump query that could also use conindid, but I left it alone because it wasn't clear it'd get any faster.)
2009-07-28 04:56:31 +02:00
trig.tgconstrindid = pkindOid;
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
trig.tgconstraint = constraintOid;
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
trig.tgdeferrable = FALSE;
trig.tginitdeferred = FALSE;
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
/* we needn't fill in tgargs or tgqual */
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
/*
* See if we can do it with a single LEFT JOIN query. A FALSE result
* indicates we must proceed with the fire-the-trigger method.
*/
if (RI_Initial_Check(&trig, rel, pkrel))
return;
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Fix up foreign-key mechanism so that there is a sound semantic basis for the 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.
2007-02-14 02:58:58 +01:00
/*
* Scan through each tuple, calling RI_FKey_check_ins (insert trigger) as
* if that tuple had just been inserted. If any of those fail, it should
* ereport(ERROR) and that's that.
*/
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
scan = heap_beginscan(rel, SnapshotNow, 0, NULL);
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
{
FunctionCallInfoData fcinfo;
Back out makeNode() patch to fix gcc 3.3.1 warning.
2003-10-14 00:47:15 +02:00
TriggerData trigdata;
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
/*
* Make a call to the trigger function
*
* No parameters are passed, but we do set a context
*/
MemSet(&fcinfo, 0, sizeof(fcinfo));
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
/*
* We assume RI_FKey_check_ins won't look at flinfo...
*/
Back out makeNode() patch to fix gcc 3.3.1 warning.
2003-10-14 00:47:15 +02:00
trigdata.type = T_TriggerData;
trigdata.tg_event = TRIGGER_EVENT_INSERT | TRIGGER_EVENT_ROW;
trigdata.tg_relation = rel;
trigdata.tg_trigtuple = tuple;
trigdata.tg_newtuple = NULL;
trigdata.tg_trigger = &trig;
I found a corner case in which it is possible for RI_FKey_check's call of HeapTupleSatisfiesItself() to trigger a hint-bit update on the tuple: if the row was updated or deleted by a subtransaction of my own transaction that was later rolled back. This cannot occur in pre-8.0 of course, so the hint-bit patch applied a couple weeks ago is OK for existing releases. But for 8.0 it seems we had better fix things so that RI_FKey_check can pass the correct buffer number to HeapTupleSatisfiesItself. Accordingly, add fields to the TriggerData struct to carry the buffer ID(s) for the old and new tuple(s). There are other possible solutions but this one seems cleanest; it will allow other AFTER-trigger functions to safely do tqual.c calls if they want to. Put new fields at end of struct so that there is no API breakage.
2004-10-30 22:53:06 +02:00
trigdata.tg_trigtuplebuf = scan->rs_cbuf;
trigdata.tg_newtuplebuf = InvalidBuffer;
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Back out makeNode() patch to fix gcc 3.3.1 warning.
2003-10-14 00:47:15 +02:00
fcinfo.context = (Node *) &trigdata;
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
RI_FKey_check_ins(&fcinfo);
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
}
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
heap_endscan(scan);
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
}
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
static void
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
CreateFKCheckTrigger(RangeVar *myRel, Constraint *fkconstraint,
Add system catalog columns pg_constraint.conindid and pg_trigger.tgconstrindid. conindid is the index supporting a constraint. We can use this not only for unique/primary-key constraints, but also foreign-key constraints, which depend on the unique index that constrains the referenced columns. tgconstrindid is just copied from the constraint's conindid field, or is zero for triggers not associated with constraints. This is mainly intended as infrastructure for upcoming patches, but it has some virtue in itself, since it exposes a relationship that you formerly had to grovel in pg_depend to determine. I simplified one information_schema view accordingly. (There is a pg_dump query that could also use conindid, but I left it alone because it wasn't clear it'd get any faster.)
2009-07-28 04:56:31 +02:00
Oid constraintOid, Oid indexOid, bool on_insert)
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
{
CreateTrigStmt *fk_trigger;
Change FK trigger naming convention to fix self-referential FKs. Use names like "RI_ConstraintTrigger_a_NNNN" for FK action triggers and "RI_ConstraintTrigger_c_NNNN" for FK check triggers. This ensures the action trigger fires first in self-referential cases where the very same row update fires both an action and a check trigger. This change provides a non-probabilistic solution for bug #6268, at the risk that it could break client code that is making assumptions about the exact names assigned to auto-generated FK triggers. Hence, change this in HEAD only. No need for forced initdb since old triggers continue to work fine.
2011-10-26 19:19:42 +02:00
/*
* Note: for a self-referential FK (referencing and referenced tables are
* the same), it is important that the ON UPDATE action fires before the
* CHECK action, since both triggers will fire on the same row during an
* UPDATE event; otherwise the CHECK trigger will be checking a non-final
* state of the row. Triggers fire in name order, so we ensure this by
* using names like "RI_ConstraintTrigger_a_NNNN" for the action triggers
* and "RI_ConstraintTrigger_c_NNNN" for the check triggers.
*/
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
fk_trigger = makeNode(CreateTrigStmt);
Change FK trigger naming convention to fix self-referential FKs. Use names like "RI_ConstraintTrigger_a_NNNN" for FK action triggers and "RI_ConstraintTrigger_c_NNNN" for FK check triggers. This ensures the action trigger fires first in self-referential cases where the very same row update fires both an action and a check trigger. This change provides a non-probabilistic solution for bug #6268, at the risk that it could break client code that is making assumptions about the exact names assigned to auto-generated FK triggers. Hence, change this in HEAD only. No need for forced initdb since old triggers continue to work fine.
2011-10-26 19:19:42 +02:00
fk_trigger->trigname = "RI_ConstraintTrigger_c";
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
fk_trigger->relation = myRel;
fk_trigger->row = true;
Support triggers on views. This patch adds the SQL-standard concept of an INSTEAD OF trigger, which is fired instead of performing a physical insert/update/delete. The trigger function is passed the entire old and/or new rows of the view, and must figure out what to do to the underlying tables to implement the update. So this feature can be used to implement updatable views using trigger programming style rather than rule hacking. In passing, this patch corrects the names of some columns in the information_schema.triggers view. It seems the SQL committee renamed them somewhere between SQL:99 and SQL:2003. Dean Rasheed, reviewed by Bernd Helmle; some additional hacking by me.
2010-10-10 19:43:33 +02:00
fk_trigger->timing = TRIGGER_TYPE_AFTER;
Create separate ON INSERT and ON UPDATE triggers on tables with foreign keys, rather than a single trigger for both events. This should not change functionality, but it is more consistent: previously, there were trigger functions for both "check_insert" and "check_update", but the former was used for both events. Bump catalog version number (not strictly necessary, but best to be cautious).
2005-05-30 08:52:38 +02:00
/* Either ON INSERT or ON UPDATE */
if (on_insert)
{
fk_trigger->funcname = SystemFuncName("RI_FKey_check_ins");
Fix the just-reported problem that you can't specify all four trigger event types in CREATE TRIGGER. While at it, clean up the amazingly tedious and inextensible way that the trigger event type list was handled. Per report from Greg Sabino Mullane.
2009-06-18 03:27:02 +02:00
fk_trigger->events = TRIGGER_TYPE_INSERT;
Create separate ON INSERT and ON UPDATE triggers on tables with foreign keys, rather than a single trigger for both events. This should not change functionality, but it is more consistent: previously, there were trigger functions for both "check_insert" and "check_update", but the former was used for both events. Bump catalog version number (not strictly necessary, but best to be cautious).
2005-05-30 08:52:38 +02:00
}
else
{
fk_trigger->funcname = SystemFuncName("RI_FKey_check_upd");
Fix the just-reported problem that you can't specify all four trigger event types in CREATE TRIGGER. While at it, clean up the amazingly tedious and inextensible way that the trigger event type list was handled. Per report from Greg Sabino Mullane.
2009-06-18 03:27:02 +02:00
fk_trigger->events = TRIGGER_TYPE_UPDATE;
Create separate ON INSERT and ON UPDATE triggers on tables with foreign keys, rather than a single trigger for both events. This should not change functionality, but it is more consistent: previously, there were trigger functions for both "check_insert" and "check_update", but the former was used for both events. Bump catalog version number (not strictly necessary, but best to be cautious).
2005-05-30 08:52:38 +02:00
}
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
fk_trigger->columns = NIL;
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
fk_trigger->whenClause = NULL;
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
fk_trigger->isconstraint = true;
fk_trigger->deferrable = fkconstraint->deferrable;
fk_trigger->initdeferred = fkconstraint->initdeferred;
fk_trigger->constrrel = fkconstraint->pktable;
fk_trigger->args = NIL;
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
(void) CreateTrigger(fk_trigger, NULL, constraintOid, indexOid, true);
Create separate ON INSERT and ON UPDATE triggers on tables with foreign keys, rather than a single trigger for both events. This should not change functionality, but it is more consistent: previously, there were trigger functions for both "check_insert" and "check_update", but the former was used for both events. Bump catalog version number (not strictly necessary, but best to be cautious).
2005-05-30 08:52:38 +02:00
/* Make changes-so-far visible */
CommandCounterIncrement();
}
/*
* Create the triggers that implement an FK constraint.
*/
static void
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
createForeignKeyTriggers(Relation rel, Constraint *fkconstraint,
Add system catalog columns pg_constraint.conindid and pg_trigger.tgconstrindid. conindid is the index supporting a constraint. We can use this not only for unique/primary-key constraints, but also foreign-key constraints, which depend on the unique index that constrains the referenced columns. tgconstrindid is just copied from the constraint's conindid field, or is zero for triggers not associated with constraints. This is mainly intended as infrastructure for upcoming patches, but it has some virtue in itself, since it exposes a relationship that you formerly had to grovel in pg_depend to determine. I simplified one information_schema view accordingly. (There is a pg_dump query that could also use conindid, but I left it alone because it wasn't clear it'd get any faster.)
2009-07-28 04:56:31 +02:00
Oid constraintOid, Oid indexOid)
Create separate ON INSERT and ON UPDATE triggers on tables with foreign keys, rather than a single trigger for both events. This should not change functionality, but it is more consistent: previously, there were trigger functions for both "check_insert" and "check_update", but the former was used for both events. Bump catalog version number (not strictly necessary, but best to be cautious).
2005-05-30 08:52:38 +02:00
{
RangeVar *myRel;
CreateTrigStmt *fk_trigger;
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Reconstruct a RangeVar for my relation (not passed in, unfortunately).
Create separate ON INSERT and ON UPDATE triggers on tables with foreign keys, rather than a single trigger for both events. This should not change functionality, but it is more consistent: previously, there were trigger functions for both "check_insert" and "check_update", but the former was used for both events. Bump catalog version number (not strictly necessary, but best to be cautious).
2005-05-30 08:52:38 +02:00
*/
myRel = makeRangeVar(get_namespace_name(RelationGetNamespace(rel)),
Add a bunch of new error location reports to parse-analysis error messages. There are still some weak spots around JOIN USING and relation alias lists, but most errors reported within backend/parser/ now have locations.
2008-09-01 22:42:46 +02:00
pstrdup(RelationGetRelationName(rel)),
-1);
Create separate ON INSERT and ON UPDATE triggers on tables with foreign keys, rather than a single trigger for both events. This should not change functionality, but it is more consistent: previously, there were trigger functions for both "check_insert" and "check_update", but the former was used for both events. Bump catalog version number (not strictly necessary, but best to be cautious).
2005-05-30 08:52:38 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Make changes-so-far visible */
CommandCounterIncrement();
/*
* Build and execute a CREATE CONSTRAINT TRIGGER statement for the ON
* DELETE action on the referenced table.
*/
fk_trigger = makeNode(CreateTrigStmt);
Change FK trigger naming convention to fix self-referential FKs. Use names like "RI_ConstraintTrigger_a_NNNN" for FK action triggers and "RI_ConstraintTrigger_c_NNNN" for FK check triggers. This ensures the action trigger fires first in self-referential cases where the very same row update fires both an action and a check trigger. This change provides a non-probabilistic solution for bug #6268, at the risk that it could break client code that is making assumptions about the exact names assigned to auto-generated FK triggers. Hence, change this in HEAD only. No need for forced initdb since old triggers continue to work fine.
2011-10-26 19:19:42 +02:00
fk_trigger->trigname = "RI_ConstraintTrigger_a";
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
fk_trigger->relation = fkconstraint->pktable;
fk_trigger->row = true;
Support triggers on views. This patch adds the SQL-standard concept of an INSTEAD OF trigger, which is fired instead of performing a physical insert/update/delete. The trigger function is passed the entire old and/or new rows of the view, and must figure out what to do to the underlying tables to implement the update. So this feature can be used to implement updatable views using trigger programming style rather than rule hacking. In passing, this patch corrects the names of some columns in the information_schema.triggers view. It seems the SQL committee renamed them somewhere between SQL:99 and SQL:2003. Dean Rasheed, reviewed by Bernd Helmle; some additional hacking by me.
2010-10-10 19:43:33 +02:00
fk_trigger->timing = TRIGGER_TYPE_AFTER;
Fix the just-reported problem that you can't specify all four trigger event types in CREATE TRIGGER. While at it, clean up the amazingly tedious and inextensible way that the trigger event type list was handled. Per report from Greg Sabino Mullane.
2009-06-18 03:27:02 +02:00
fk_trigger->events = TRIGGER_TYPE_DELETE;
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
fk_trigger->columns = NIL;
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
fk_trigger->whenClause = NULL;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
fk_trigger->isconstraint = true;
fk_trigger->constrrel = myRel;
switch (fkconstraint->fk_del_action)
{
case FKCONSTR_ACTION_NOACTION:
Disallow referential integrity actions from being deferred; only the NO ACTION check is deferrable. This seems to be a closer approximation to what the SQL spec says than what we were doing before, and it prevents some anomalous behaviors that are possible now that triggers can fire during the execution of PL functions. Stephan Szabo.
2004-10-21 23:33:59 +02:00
fk_trigger->deferrable = fkconstraint->deferrable;
fk_trigger->initdeferred = fkconstraint->initdeferred;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
fk_trigger->funcname = SystemFuncName("RI_FKey_noaction_del");
break;
case FKCONSTR_ACTION_RESTRICT:
fk_trigger->deferrable = false;
fk_trigger->initdeferred = false;
fk_trigger->funcname = SystemFuncName("RI_FKey_restrict_del");
break;
case FKCONSTR_ACTION_CASCADE:
Disallow referential integrity actions from being deferred; only the NO ACTION check is deferrable. This seems to be a closer approximation to what the SQL spec says than what we were doing before, and it prevents some anomalous behaviors that are possible now that triggers can fire during the execution of PL functions. Stephan Szabo.
2004-10-21 23:33:59 +02:00
fk_trigger->deferrable = false;
fk_trigger->initdeferred = false;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
fk_trigger->funcname = SystemFuncName("RI_FKey_cascade_del");
break;
case FKCONSTR_ACTION_SETNULL:
Disallow referential integrity actions from being deferred; only the NO ACTION check is deferrable. This seems to be a closer approximation to what the SQL spec says than what we were doing before, and it prevents some anomalous behaviors that are possible now that triggers can fire during the execution of PL functions. Stephan Szabo.
2004-10-21 23:33:59 +02:00
fk_trigger->deferrable = false;
fk_trigger->initdeferred = false;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
fk_trigger->funcname = SystemFuncName("RI_FKey_setnull_del");
break;
case FKCONSTR_ACTION_SETDEFAULT:
Disallow referential integrity actions from being deferred; only the NO ACTION check is deferrable. This seems to be a closer approximation to what the SQL spec says than what we were doing before, and it prevents some anomalous behaviors that are possible now that triggers can fire during the execution of PL functions. Stephan Szabo.
2004-10-21 23:33:59 +02:00
fk_trigger->deferrable = false;
fk_trigger->initdeferred = false;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
fk_trigger->funcname = SystemFuncName("RI_FKey_setdefault_del");
break;
default:
elog(ERROR, "unrecognized FK action type: %d",
(int) fkconstraint->fk_del_action);
break;
}
fk_trigger->args = NIL;
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
(void) CreateTrigger(fk_trigger, NULL, constraintOid, indexOid, true);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Make changes-so-far visible */
CommandCounterIncrement();
/*
* Build and execute a CREATE CONSTRAINT TRIGGER statement for the ON
* UPDATE action on the referenced table.
*/
fk_trigger = makeNode(CreateTrigStmt);
Change FK trigger naming convention to fix self-referential FKs. Use names like "RI_ConstraintTrigger_a_NNNN" for FK action triggers and "RI_ConstraintTrigger_c_NNNN" for FK check triggers. This ensures the action trigger fires first in self-referential cases where the very same row update fires both an action and a check trigger. This change provides a non-probabilistic solution for bug #6268, at the risk that it could break client code that is making assumptions about the exact names assigned to auto-generated FK triggers. Hence, change this in HEAD only. No need for forced initdb since old triggers continue to work fine.
2011-10-26 19:19:42 +02:00
fk_trigger->trigname = "RI_ConstraintTrigger_a";
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
fk_trigger->relation = fkconstraint->pktable;
fk_trigger->row = true;
Support triggers on views. This patch adds the SQL-standard concept of an INSTEAD OF trigger, which is fired instead of performing a physical insert/update/delete. The trigger function is passed the entire old and/or new rows of the view, and must figure out what to do to the underlying tables to implement the update. So this feature can be used to implement updatable views using trigger programming style rather than rule hacking. In passing, this patch corrects the names of some columns in the information_schema.triggers view. It seems the SQL committee renamed them somewhere between SQL:99 and SQL:2003. Dean Rasheed, reviewed by Bernd Helmle; some additional hacking by me.
2010-10-10 19:43:33 +02:00
fk_trigger->timing = TRIGGER_TYPE_AFTER;
Fix the just-reported problem that you can't specify all four trigger event types in CREATE TRIGGER. While at it, clean up the amazingly tedious and inextensible way that the trigger event type list was handled. Per report from Greg Sabino Mullane.
2009-06-18 03:27:02 +02:00
fk_trigger->events = TRIGGER_TYPE_UPDATE;
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
fk_trigger->columns = NIL;
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
fk_trigger->whenClause = NULL;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
fk_trigger->isconstraint = true;
fk_trigger->constrrel = myRel;
switch (fkconstraint->fk_upd_action)
{
case FKCONSTR_ACTION_NOACTION:
Disallow referential integrity actions from being deferred; only the NO ACTION check is deferrable. This seems to be a closer approximation to what the SQL spec says than what we were doing before, and it prevents some anomalous behaviors that are possible now that triggers can fire during the execution of PL functions. Stephan Szabo.
2004-10-21 23:33:59 +02:00
fk_trigger->deferrable = fkconstraint->deferrable;
fk_trigger->initdeferred = fkconstraint->initdeferred;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
fk_trigger->funcname = SystemFuncName("RI_FKey_noaction_upd");
break;
case FKCONSTR_ACTION_RESTRICT:
fk_trigger->deferrable = false;
fk_trigger->initdeferred = false;
fk_trigger->funcname = SystemFuncName("RI_FKey_restrict_upd");
break;
case FKCONSTR_ACTION_CASCADE:
Disallow referential integrity actions from being deferred; only the NO ACTION check is deferrable. This seems to be a closer approximation to what the SQL spec says than what we were doing before, and it prevents some anomalous behaviors that are possible now that triggers can fire during the execution of PL functions. Stephan Szabo.
2004-10-21 23:33:59 +02:00
fk_trigger->deferrable = false;
fk_trigger->initdeferred = false;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
fk_trigger->funcname = SystemFuncName("RI_FKey_cascade_upd");
break;
case FKCONSTR_ACTION_SETNULL:
Disallow referential integrity actions from being deferred; only the NO ACTION check is deferrable. This seems to be a closer approximation to what the SQL spec says than what we were doing before, and it prevents some anomalous behaviors that are possible now that triggers can fire during the execution of PL functions. Stephan Szabo.
2004-10-21 23:33:59 +02:00
fk_trigger->deferrable = false;
fk_trigger->initdeferred = false;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
fk_trigger->funcname = SystemFuncName("RI_FKey_setnull_upd");
break;
case FKCONSTR_ACTION_SETDEFAULT:
Disallow referential integrity actions from being deferred; only the NO ACTION check is deferrable. This seems to be a closer approximation to what the SQL spec says than what we were doing before, and it prevents some anomalous behaviors that are possible now that triggers can fire during the execution of PL functions. Stephan Szabo.
2004-10-21 23:33:59 +02:00
fk_trigger->deferrable = false;
fk_trigger->initdeferred = false;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
fk_trigger->funcname = SystemFuncName("RI_FKey_setdefault_upd");
break;
default:
elog(ERROR, "unrecognized FK action type: %d",
(int) fkconstraint->fk_upd_action);
break;
}
fk_trigger->args = NIL;
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
(void) CreateTrigger(fk_trigger, NULL, constraintOid, indexOid, true);
Change FK trigger creation order to better support self-referential FKs. When a foreign-key constraint references another column of the same table, row updates will queue both the PK's ON UPDATE action and the FK's CHECK action in the same event. The ON UPDATE action must execute first, else the CHECK will check a non-final state of the row and possibly throw an inappropriate error, as seen in bug #6268 from Roman Lytovchenko. Now, the firing order of multiple triggers for the same event is determined by the sort order of their pg_trigger.tgnames, and the auto-generated names we use for FK triggers are "RI_ConstraintTrigger_NNNN" where NNNN is the trigger OID. So most of the time the firing order is the same as creation order, and so rearranging the creation order fixes it. This patch will fail to fix the problem if the OID counter wraps around or adds a decimal digit (eg, from 99999 to 100000) while we are creating the triggers for an FK constraint. Given the small odds of that, and the low usage of self-referential FKs, we'll live with that solution in the back branches. A better fix is to change the auto-generated names for FK triggers, but it seems unwise to do that in stable branches because there may be client code that depends on the naming convention. We'll fix it that way in HEAD in a separate patch. Back-patch to all supported branches, since this bug has existed for a long time.
2011-10-26 19:02:28 +02:00
/* Make changes-so-far visible */
CommandCounterIncrement();
/*
* Build and execute CREATE CONSTRAINT TRIGGER statements for the CHECK
* action for both INSERTs and UPDATEs on the referencing table.
*/
CreateFKCheckTrigger(myRel, fkconstraint, constraintOid, indexOid, true);
CreateFKCheckTrigger(myRel, fkconstraint, constraintOid, indexOid, false);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
/*
* ALTER TABLE DROP CONSTRAINT
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
*
* Like DROP COLUMN, we can't use the normal ALTER TABLE recursion mechanism.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
static void
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
ATExecDropConstraint(Relation rel, const char *constrName,
DropBehavior behavior,
DROP IF EXISTS for columns and constraints. Andres Freund.
2009-07-20 04:42:28 +02:00
bool recurse, bool recursing,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
bool missing_ok, LOCKMODE lockmode)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
List *children;
ListCell *child;
Relation conrel;
Form_pg_constraint con;
SysScanDesc scan;
ScanKeyData key;
HeapTuple tuple;
bool found = false;
Recast "ONLY" column CHECK constraints as NO INHERIT The original syntax wasn't universally loved, and it didn't allow its usage in CREATE TABLE, only ALTER TABLE. It now works everywhere, and it also allows using ALTER TABLE ONLY to add an uninherited CHECK constraint, per discussion. The pg_constraint column has accordingly been renamed connoinherit. This commit partly reverts some of the changes in 61d81bd28dbec65a6b144e0cd3d0bfe25913c3ac, particularly some pg_dump and psql bits, because now pg_get_constraintdef includes the necessary NO INHERIT within the constraint definition. Author: Nikhil Sontakke Some tweaks by me
2012-04-21 04:46:20 +02:00
bool is_no_inherit_constraint = false;
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
/* At top level, permission check was done in ATPrepCmd, else do it */
if (recursing)
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
ATSimplePermissions(rel, ATT_TABLE);
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
conrel = heap_open(ConstraintRelationId, RowExclusiveLock);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
* Find and drop the target constraint
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
ScanKeyInit(&key,
Anum_pg_constraint_conrelid,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(RelationGetRelid(rel)));
scan = systable_beginscan(conrel, ConstraintRelidIndexId,
true, SnapshotNow, 1, &key);
while (HeapTupleIsValid(tuple = systable_getnext(scan)))
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
ObjectAddress conobj;
con = (Form_pg_constraint) GETSTRUCT(tuple);
if (strcmp(NameStr(con->conname), constrName) != 0)
continue;
/* Don't drop inherited constraints */
if (con->coninhcount > 0 && !recursing)
ereport(ERROR,
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
errmsg("cannot drop inherited constraint \"%s\" of relation \"%s\"",
constrName, RelationGetRelationName(rel))));
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
Recast "ONLY" column CHECK constraints as NO INHERIT The original syntax wasn't universally loved, and it didn't allow its usage in CREATE TABLE, only ALTER TABLE. It now works everywhere, and it also allows using ALTER TABLE ONLY to add an uninherited CHECK constraint, per discussion. The pg_constraint column has accordingly been renamed connoinherit. This commit partly reverts some of the changes in 61d81bd28dbec65a6b144e0cd3d0bfe25913c3ac, particularly some pg_dump and psql bits, because now pg_get_constraintdef includes the necessary NO INHERIT within the constraint definition. Author: Nikhil Sontakke Some tweaks by me
2012-04-21 04:46:20 +02:00
is_no_inherit_constraint = con->connoinherit;
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
/*
* Perform the actual constraint deletion
*/
conobj.classId = ConstraintRelationId;
conobj.objectId = HeapTupleGetOid(tuple);
conobj.objectSubId = 0;
Classify DROP operations by whether or not they are user-initiated. This doesn't do anything useful just yet, but is intended as supporting infrastructure for allowing sepgsql to sensibly check DROP permissions. KaiGai Kohei and Robert Haas
2012-01-26 15:24:54 +01:00
performDeletion(&conobj, behavior, 0);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
found = true;
Allow CHECK constraints to be declared ONLY This makes them enforceable only on the parent table, not on children tables. This is useful in various situations, per discussion involving people bitten by the restrictive behavior introduced in 8.4. Message-Id: 8762mp93iw.fsf@comcast.net CAFaPBrSMMpubkGf4zcRL_YL-AERUbYF_-ZNNYfb3CVwwEqc9TQ@mail.gmail.com Authors: Nikhil Sontakke, Alex Hunsaker Reviewed by Robert Haas and myself
2011-12-05 19:10:18 +01:00
/* constraint found and dropped -- no need to keep looping */
break;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
systable_endscan(scan);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
if (!found)
{
if (!missing_ok)
{
DROP IF EXISTS for columns and constraints. Andres Freund.
2009-07-20 04:42:28 +02:00
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_OBJECT),
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
errmsg("constraint \"%s\" of relation \"%s\" does not exist",
constrName, RelationGetRelationName(rel))));
DROP IF EXISTS for columns and constraints. Andres Freund.
2009-07-20 04:42:28 +02:00
}
else
{
ereport(NOTICE,
(errmsg("constraint \"%s\" of relation \"%s\" does not exist, skipping",
constrName, RelationGetRelationName(rel))));
heap_close(conrel, RowExclusiveLock);
return;
}
}
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
/*
* Propagate to children as appropriate. Unlike most other ALTER
* routines, we have to do this one level of recursion at a time; we can't
* use find_all_inheritors to do it in one pass.
*/
Recast "ONLY" column CHECK constraints as NO INHERIT The original syntax wasn't universally loved, and it didn't allow its usage in CREATE TABLE, only ALTER TABLE. It now works everywhere, and it also allows using ALTER TABLE ONLY to add an uninherited CHECK constraint, per discussion. The pg_constraint column has accordingly been renamed connoinherit. This commit partly reverts some of the changes in 61d81bd28dbec65a6b144e0cd3d0bfe25913c3ac, particularly some pg_dump and psql bits, because now pg_get_constraintdef includes the necessary NO INHERIT within the constraint definition. Author: Nikhil Sontakke Some tweaks by me
2012-04-21 04:46:20 +02:00
if (!is_no_inherit_constraint)
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
children = find_inheritance_children(RelationGetRelid(rel), lockmode);
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
else
children = NIL;
foreach(child, children)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
Oid childrelid = lfirst_oid(child);
Relation childrel;
Fix ALTER TABLE ONLY .. DROP CONSTRAINT. When I consolidated two copies of the HOT-chain search logic in commit 4da99ea4231e3d8bbf28b666748c1028e7b7d665, I introduced a behavior change: the old code wouldn't necessarily traverse the entire chain, if the most recently returned tuple were updated while the HOT chain traversal is in progress. The new behavior seems more correct, but unfortunately, the code here relies on a scan with SnapshotNow failing to see its own updates. That seems pretty shaky even with the old HOT chain traversal behavior, since there's no guarantee that these updates will always be HOT, but it's trivial to broke a failure with the new HOT search logic. Fix by updating just the first matching pg_constraint tuple, rather than all of them, since there should be only one anyway. But since nobody has reproduced this failure on older versions, no back-patch for now. Report and test case by Alex Hunsaker; tablecmds.c changes by me.
2011-10-10 05:39:52 +02:00
HeapTuple copy_tuple;
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
Modify find_inheritance_children() and find_all_inheritors() to add the ability to lock relations as they scan pg_inherits, and to ignore any relations that have disappeared by the time we get lock on them. This makes uses of these functions safe against concurrent DROP operations on child tables: we will effectively ignore any just-dropped child, rather than possibly throwing an error as in recent bug report from Thomas Johansson (and similar past complaints). The behavior should not change otherwise, since the code was acquiring those same locks anyway, just a little bit later. An exception is LockTableCommand(), which is still behaving unsafely; but that seems to require some more discussion before we change it.
2009-05-12 05:11:02 +02:00
/* find_inheritance_children already got lock */
childrel = heap_open(childrelid, NoLock);
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
CheckTableNotInUse(childrel, "ALTER TABLE");
ScanKeyInit(&key,
Anum_pg_constraint_conrelid,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(childrelid));
scan = systable_beginscan(conrel, ConstraintRelidIndexId,
true, SnapshotNow, 1, &key);
Fix ALTER TABLE ONLY .. DROP CONSTRAINT. When I consolidated two copies of the HOT-chain search logic in commit 4da99ea4231e3d8bbf28b666748c1028e7b7d665, I introduced a behavior change: the old code wouldn't necessarily traverse the entire chain, if the most recently returned tuple were updated while the HOT chain traversal is in progress. The new behavior seems more correct, but unfortunately, the code here relies on a scan with SnapshotNow failing to see its own updates. That seems pretty shaky even with the old HOT chain traversal behavior, since there's no guarantee that these updates will always be HOT, but it's trivial to broke a failure with the new HOT search logic. Fix by updating just the first matching pg_constraint tuple, rather than all of them, since there should be only one anyway. But since nobody has reproduced this failure on older versions, no back-patch for now. Report and test case by Alex Hunsaker; tablecmds.c changes by me.
2011-10-10 05:39:52 +02:00
/* scan for matching tuple - there should only be one */
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
while (HeapTupleIsValid(tuple = systable_getnext(scan)))
{
con = (Form_pg_constraint) GETSTRUCT(tuple);
/* Right now only CHECK constraints can be inherited */
if (con->contype != CONSTRAINT_CHECK)
continue;
Fix ALTER TABLE ONLY .. DROP CONSTRAINT. When I consolidated two copies of the HOT-chain search logic in commit 4da99ea4231e3d8bbf28b666748c1028e7b7d665, I introduced a behavior change: the old code wouldn't necessarily traverse the entire chain, if the most recently returned tuple were updated while the HOT chain traversal is in progress. The new behavior seems more correct, but unfortunately, the code here relies on a scan with SnapshotNow failing to see its own updates. That seems pretty shaky even with the old HOT chain traversal behavior, since there's no guarantee that these updates will always be HOT, but it's trivial to broke a failure with the new HOT search logic. Fix by updating just the first matching pg_constraint tuple, rather than all of them, since there should be only one anyway. But since nobody has reproduced this failure on older versions, no back-patch for now. Report and test case by Alex Hunsaker; tablecmds.c changes by me.
2011-10-10 05:39:52 +02:00
if (strcmp(NameStr(con->conname), constrName) == 0)
break;
}
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
Fix ALTER TABLE ONLY .. DROP CONSTRAINT. When I consolidated two copies of the HOT-chain search logic in commit 4da99ea4231e3d8bbf28b666748c1028e7b7d665, I introduced a behavior change: the old code wouldn't necessarily traverse the entire chain, if the most recently returned tuple were updated while the HOT chain traversal is in progress. The new behavior seems more correct, but unfortunately, the code here relies on a scan with SnapshotNow failing to see its own updates. That seems pretty shaky even with the old HOT chain traversal behavior, since there's no guarantee that these updates will always be HOT, but it's trivial to broke a failure with the new HOT search logic. Fix by updating just the first matching pg_constraint tuple, rather than all of them, since there should be only one anyway. But since nobody has reproduced this failure on older versions, no back-patch for now. Report and test case by Alex Hunsaker; tablecmds.c changes by me.
2011-10-10 05:39:52 +02:00
if (!HeapTupleIsValid(tuple))
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_OBJECT),
errmsg("constraint \"%s\" of relation \"%s\" does not exist",
constrName,
RelationGetRelationName(childrel))));
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
Fix ALTER TABLE ONLY .. DROP CONSTRAINT. When I consolidated two copies of the HOT-chain search logic in commit 4da99ea4231e3d8bbf28b666748c1028e7b7d665, I introduced a behavior change: the old code wouldn't necessarily traverse the entire chain, if the most recently returned tuple were updated while the HOT chain traversal is in progress. The new behavior seems more correct, but unfortunately, the code here relies on a scan with SnapshotNow failing to see its own updates. That seems pretty shaky even with the old HOT chain traversal behavior, since there's no guarantee that these updates will always be HOT, but it's trivial to broke a failure with the new HOT search logic. Fix by updating just the first matching pg_constraint tuple, rather than all of them, since there should be only one anyway. But since nobody has reproduced this failure on older versions, no back-patch for now. Report and test case by Alex Hunsaker; tablecmds.c changes by me.
2011-10-10 05:39:52 +02:00
copy_tuple = heap_copytuple(tuple);
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
Fix ALTER TABLE ONLY .. DROP CONSTRAINT. When I consolidated two copies of the HOT-chain search logic in commit 4da99ea4231e3d8bbf28b666748c1028e7b7d665, I introduced a behavior change: the old code wouldn't necessarily traverse the entire chain, if the most recently returned tuple were updated while the HOT chain traversal is in progress. The new behavior seems more correct, but unfortunately, the code here relies on a scan with SnapshotNow failing to see its own updates. That seems pretty shaky even with the old HOT chain traversal behavior, since there's no guarantee that these updates will always be HOT, but it's trivial to broke a failure with the new HOT search logic. Fix by updating just the first matching pg_constraint tuple, rather than all of them, since there should be only one anyway. But since nobody has reproduced this failure on older versions, no back-patch for now. Report and test case by Alex Hunsaker; tablecmds.c changes by me.
2011-10-10 05:39:52 +02:00
systable_endscan(scan);
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
Fix ALTER TABLE ONLY .. DROP CONSTRAINT. When I consolidated two copies of the HOT-chain search logic in commit 4da99ea4231e3d8bbf28b666748c1028e7b7d665, I introduced a behavior change: the old code wouldn't necessarily traverse the entire chain, if the most recently returned tuple were updated while the HOT chain traversal is in progress. The new behavior seems more correct, but unfortunately, the code here relies on a scan with SnapshotNow failing to see its own updates. That seems pretty shaky even with the old HOT chain traversal behavior, since there's no guarantee that these updates will always be HOT, but it's trivial to broke a failure with the new HOT search logic. Fix by updating just the first matching pg_constraint tuple, rather than all of them, since there should be only one anyway. But since nobody has reproduced this failure on older versions, no back-patch for now. Report and test case by Alex Hunsaker; tablecmds.c changes by me.
2011-10-10 05:39:52 +02:00
con = (Form_pg_constraint) GETSTRUCT(copy_tuple);
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
if (con->coninhcount <= 0) /* shouldn't happen */
Fix ALTER TABLE ONLY .. DROP CONSTRAINT. When I consolidated two copies of the HOT-chain search logic in commit 4da99ea4231e3d8bbf28b666748c1028e7b7d665, I introduced a behavior change: the old code wouldn't necessarily traverse the entire chain, if the most recently returned tuple were updated while the HOT chain traversal is in progress. The new behavior seems more correct, but unfortunately, the code here relies on a scan with SnapshotNow failing to see its own updates. That seems pretty shaky even with the old HOT chain traversal behavior, since there's no guarantee that these updates will always be HOT, but it's trivial to broke a failure with the new HOT search logic. Fix by updating just the first matching pg_constraint tuple, rather than all of them, since there should be only one anyway. But since nobody has reproduced this failure on older versions, no back-patch for now. Report and test case by Alex Hunsaker; tablecmds.c changes by me.
2011-10-10 05:39:52 +02:00
elog(ERROR, "relation %u has non-inherited constraint \"%s\"",
childrelid, constrName);
if (recurse)
{
/*
* If the child constraint has other definition sources, just
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* decrement its inheritance count; if not, recurse to delete it.
Fix ALTER TABLE ONLY .. DROP CONSTRAINT. When I consolidated two copies of the HOT-chain search logic in commit 4da99ea4231e3d8bbf28b666748c1028e7b7d665, I introduced a behavior change: the old code wouldn't necessarily traverse the entire chain, if the most recently returned tuple were updated while the HOT chain traversal is in progress. The new behavior seems more correct, but unfortunately, the code here relies on a scan with SnapshotNow failing to see its own updates. That seems pretty shaky even with the old HOT chain traversal behavior, since there's no guarantee that these updates will always be HOT, but it's trivial to broke a failure with the new HOT search logic. Fix by updating just the first matching pg_constraint tuple, rather than all of them, since there should be only one anyway. But since nobody has reproduced this failure on older versions, no back-patch for now. Report and test case by Alex Hunsaker; tablecmds.c changes by me.
2011-10-10 05:39:52 +02:00
*/
if (con->coninhcount == 1 && !con->conislocal)
{
/* Time to delete this child constraint, too */
ATExecDropConstraint(childrel, constrName, behavior,
true, true,
false, lockmode);
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
}
else
{
Fix ALTER TABLE ONLY .. DROP CONSTRAINT. When I consolidated two copies of the HOT-chain search logic in commit 4da99ea4231e3d8bbf28b666748c1028e7b7d665, I introduced a behavior change: the old code wouldn't necessarily traverse the entire chain, if the most recently returned tuple were updated while the HOT chain traversal is in progress. The new behavior seems more correct, but unfortunately, the code here relies on a scan with SnapshotNow failing to see its own updates. That seems pretty shaky even with the old HOT chain traversal behavior, since there's no guarantee that these updates will always be HOT, but it's trivial to broke a failure with the new HOT search logic. Fix by updating just the first matching pg_constraint tuple, rather than all of them, since there should be only one anyway. But since nobody has reproduced this failure on older versions, no back-patch for now. Report and test case by Alex Hunsaker; tablecmds.c changes by me.
2011-10-10 05:39:52 +02:00
/* Child constraint must survive my deletion */
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
con->coninhcount--;
simple_heap_update(conrel, &copy_tuple->t_self, copy_tuple);
CatalogUpdateIndexes(conrel, copy_tuple);
/* Make update visible */
CommandCounterIncrement();
}
}
Fix ALTER TABLE ONLY .. DROP CONSTRAINT. When I consolidated two copies of the HOT-chain search logic in commit 4da99ea4231e3d8bbf28b666748c1028e7b7d665, I introduced a behavior change: the old code wouldn't necessarily traverse the entire chain, if the most recently returned tuple were updated while the HOT chain traversal is in progress. The new behavior seems more correct, but unfortunately, the code here relies on a scan with SnapshotNow failing to see its own updates. That seems pretty shaky even with the old HOT chain traversal behavior, since there's no guarantee that these updates will always be HOT, but it's trivial to broke a failure with the new HOT search logic. Fix by updating just the first matching pg_constraint tuple, rather than all of them, since there should be only one anyway. But since nobody has reproduced this failure on older versions, no back-patch for now. Report and test case by Alex Hunsaker; tablecmds.c changes by me.
2011-10-10 05:39:52 +02:00
else
{
/*
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* If we were told to drop ONLY in this table (no recursion), we
* need to mark the inheritors' constraints as locally defined
* rather than inherited.
Fix ALTER TABLE ONLY .. DROP CONSTRAINT. When I consolidated two copies of the HOT-chain search logic in commit 4da99ea4231e3d8bbf28b666748c1028e7b7d665, I introduced a behavior change: the old code wouldn't necessarily traverse the entire chain, if the most recently returned tuple were updated while the HOT chain traversal is in progress. The new behavior seems more correct, but unfortunately, the code here relies on a scan with SnapshotNow failing to see its own updates. That seems pretty shaky even with the old HOT chain traversal behavior, since there's no guarantee that these updates will always be HOT, but it's trivial to broke a failure with the new HOT search logic. Fix by updating just the first matching pg_constraint tuple, rather than all of them, since there should be only one anyway. But since nobody has reproduced this failure on older versions, no back-patch for now. Report and test case by Alex Hunsaker; tablecmds.c changes by me.
2011-10-10 05:39:52 +02:00
*/
con->coninhcount--;
con->conislocal = true;
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
Fix ALTER TABLE ONLY .. DROP CONSTRAINT. When I consolidated two copies of the HOT-chain search logic in commit 4da99ea4231e3d8bbf28b666748c1028e7b7d665, I introduced a behavior change: the old code wouldn't necessarily traverse the entire chain, if the most recently returned tuple were updated while the HOT chain traversal is in progress. The new behavior seems more correct, but unfortunately, the code here relies on a scan with SnapshotNow failing to see its own updates. That seems pretty shaky even with the old HOT chain traversal behavior, since there's no guarantee that these updates will always be HOT, but it's trivial to broke a failure with the new HOT search logic. Fix by updating just the first matching pg_constraint tuple, rather than all of them, since there should be only one anyway. But since nobody has reproduced this failure on older versions, no back-patch for now. Report and test case by Alex Hunsaker; tablecmds.c changes by me.
2011-10-10 05:39:52 +02:00
simple_heap_update(conrel, &copy_tuple->t_self, copy_tuple);
CatalogUpdateIndexes(conrel, copy_tuple);
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
Fix ALTER TABLE ONLY .. DROP CONSTRAINT. When I consolidated two copies of the HOT-chain search logic in commit 4da99ea4231e3d8bbf28b666748c1028e7b7d665, I introduced a behavior change: the old code wouldn't necessarily traverse the entire chain, if the most recently returned tuple were updated while the HOT chain traversal is in progress. The new behavior seems more correct, but unfortunately, the code here relies on a scan with SnapshotNow failing to see its own updates. That seems pretty shaky even with the old HOT chain traversal behavior, since there's no guarantee that these updates will always be HOT, but it's trivial to broke a failure with the new HOT search logic. Fix by updating just the first matching pg_constraint tuple, rather than all of them, since there should be only one anyway. But since nobody has reproduced this failure on older versions, no back-patch for now. Report and test case by Alex Hunsaker; tablecmds.c changes by me.
2011-10-10 05:39:52 +02:00
/* Make update visible */
CommandCounterIncrement();
}
heap_freetuple(copy_tuple);
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
heap_close(childrel, NoLock);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
heap_close(conrel, RowExclusiveLock);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
/*
* ALTER COLUMN TYPE
*/
static void
ATPrepAlterColumnType(List **wqueue,
AlteredTableInfo *tab, Relation rel,
bool recurse, bool recursing,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
AlterTableCmd *cmd, LOCKMODE lockmode)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
char *colName = cmd->name;
Remove collation information from TypeName, where it does not belong. 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.
2011-03-10 04:38:52 +01:00
ColumnDef *def = (ColumnDef *) cmd->def;
TypeName *typeName = def->typeName;
Node *transform = def->raw_default;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
HeapTuple tuple;
Form_pg_attribute attTup;
AttrNumber attnum;
Oid targettype;
Support type modifiers for user-defined types, and pull most knowledge about typmod representation for standard types out into type-specific typmod I/O functions. Teodor Sigaev, with some editorialization by Tom Lane.
2006-12-30 22:21:56 +01:00
int32 targettypmod;
Per-column collation support 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
2011-02-08 22:04:18 +01:00
Oid targetcollid;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
NewColumnValue *newval;
ParseState *pstate = make_parsestate(NULL);
Add support for privileges on types This adds support for the more or less SQL-conforming USAGE privilege on types and domains. The intent is to be able restrict which users can create dependencies on types, which restricts the way in which owners can alter types. reviewed by Yeb Havinga
2011-12-19 23:05:19 +01:00
AclResult aclresult;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
if (rel->rd_rel->reloftype && !recursing)
Add more checks against altering typed tables - Prohibit altering column type - Prohibit changing inheritance - Move checks from Exec to Prep phases in ALTER TABLE code backpatched to 9.0
2010-07-23 22:04:18 +02:00
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("cannot alter column type of typed table")));
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* lookup the attribute so we can check inheritance status */
tuple = SearchSysCacheAttName(RelationGetRelid(rel), colName);
if (!HeapTupleIsValid(tuple))
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_COLUMN),
errmsg("column \"%s\" of relation \"%s\" does not exist",
colName, RelationGetRelationName(rel))));
attTup = (Form_pg_attribute) GETSTRUCT(tuple);
attnum = attTup->attnum;
/* Can't alter a system attribute */
if (attnum <= 0)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot alter system column \"%s\"",
colName)));
/* Don't alter inherited columns */
if (attTup->attinhcount > 0 && !recursing)
ereport(ERROR,
(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
errmsg("cannot alter inherited column \"%s\"",
colName)));
/* Look up the target type */
Remove collation information from TypeName, where it does not belong. 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.
2011-03-10 04:38:52 +01:00
typenameTypeIdAndMod(NULL, typeName, &targettype, &targettypmod);
Add support for privileges on types This adds support for the more or less SQL-conforming USAGE privilege on types and domains. The intent is to be able restrict which users can create dependencies on types, which restricts the way in which owners can alter types. reviewed by Yeb Havinga
2011-12-19 23:05:19 +01:00
aclresult = pg_type_aclcheck(targettype, GetUserId(), ACL_USAGE);
if (aclresult != ACLCHECK_OK)
Improve reporting of permission errors for array types Because permissions are assigned to element types, not array types, complaining about permission denied on an array type would be misleading to users. So adjust the reporting to refer to the element type instead. In order not to duplicate the required logic in two dozen places, refactor the permission denied reporting for types a bit. pointed out by Yeb Havinga during the review of the type privilege feature
2012-06-15 21:55:03 +02:00
aclcheck_error_type(aclresult, targettype);
Add support for privileges on types This adds support for the more or less SQL-conforming USAGE privilege on types and domains. The intent is to be able restrict which users can create dependencies on types, which restricts the way in which owners can alter types. reviewed by Yeb Havinga
2011-12-19 23:05:19 +01:00
Remove collation information from TypeName, where it does not belong. 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.
2011-03-10 04:38:52 +01:00
/* And the collation */
targetcollid = GetColumnDefCollation(NULL, def, targettype);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* make sure datatype is legal for a column */
Prevent a rowtype from being included in itself. 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.
2011-03-28 21:44:54 +02:00
CheckAttributeType(colName, targettype, targetcollid,
list_make1_oid(rel->rd_rel->reltype),
false);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Add ALTER TYPE ... ADD/DROP/ALTER/RENAME ATTRIBUTE Like with tables, this also requires allowing the existence of composite types with zero attributes. reviewed by KaiGai Kohei
2010-09-26 13:41:03 +02:00
if (tab->relkind == RELKIND_RELATION)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
Add ALTER TYPE ... ADD/DROP/ALTER/RENAME ATTRIBUTE Like with tables, this also requires allowing the existence of composite types with zero attributes. reviewed by KaiGai Kohei
2010-09-26 13:41:03 +02:00
/*
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
* Set up an expression to transform the old data value to the new
* type. If a USING option was given, transform and use that
* expression, else just take the old value and try to coerce it. We
* do this first so that type incompatibility can be detected before
* we waste effort, and because we need the expression to be parsed
Message style and spelling improvements
2011-06-21 23:33:20 +02:00
* against the original table row type.
Add ALTER TYPE ... ADD/DROP/ALTER/RENAME ATTRIBUTE Like with tables, this also requires allowing the existence of composite types with zero attributes. reviewed by KaiGai Kohei
2010-09-26 13:41:03 +02:00
*/
Remove collation information from TypeName, where it does not belong. 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.
2011-03-10 04:38:52 +01:00
if (transform)
Add ALTER TYPE ... ADD/DROP/ALTER/RENAME ATTRIBUTE Like with tables, this also requires allowing the existence of composite types with zero attributes. reviewed by KaiGai Kohei
2010-09-26 13:41:03 +02:00
{
RangeTblEntry *rte;
/* Expression must be able to access vars of old table */
rte = addRangeTableEntryForRelation(pstate,
rel,
NULL,
false,
true);
addRTEtoQuery(pstate, rte, false, true, true);
Centralize the logic for detecting misplaced aggregates, window funcs, etc. Formerly we relied on checking after-the-fact to see if an expression contained aggregates, window functions, or sub-selects when it shouldn't. This is grotty, easily forgotten (indeed, we had forgotten to teach DefineIndex about rejecting window functions), and none too efficient since it requires extra traversals of the parse tree. To improve matters, define an enum type that classifies all SQL sub-expressions, store it in ParseState to show what kind of expression we are currently parsing, and make transformAggregateCall, transformWindowFuncCall, and transformSubLink check the expression type and throw error if the type indicates the construct is disallowed. This allows removal of a large number of ad-hoc checks scattered around the code base. The enum type is sufficiently fine-grained that we can still produce error messages of at least the same specificity as before. Bringing these error checks together revealed that we'd been none too consistent about phrasing of the error messages, so standardize the wording a bit. Also, rewrite checking of aggregate arguments so that it requires only one traversal of the arguments, rather than up to three as before. In passing, clean up some more comments left over from add_missing_from support, and annotate some tests that I think are dead code now that that's gone. (I didn't risk actually removing said dead code, though.)
2012-08-10 17:35:33 +02:00
transform = transformExpr(pstate, transform,
EXPR_KIND_ALTER_COL_TRANSFORM);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Add ALTER TYPE ... ADD/DROP/ALTER/RENAME ATTRIBUTE Like with tables, this also requires allowing the existence of composite types with zero attributes. reviewed by KaiGai Kohei
2010-09-26 13:41:03 +02:00
/* It can't return a set */
if (expression_returns_set(transform))
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
errmsg("transform expression must not return a set")));
Add ALTER TYPE ... ADD/DROP/ALTER/RENAME ATTRIBUTE Like with tables, this also requires allowing the existence of composite types with zero attributes. reviewed by KaiGai Kohei
2010-09-26 13:41:03 +02:00
}
else
{
transform = (Node *) makeVar(1, attnum,
Make a code-cleanup pass over the collations patch. 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().
2011-04-22 23:43:18 +02:00
attTup->atttypid, attTup->atttypmod,
attTup->attcollation,
Add ALTER TYPE ... ADD/DROP/ALTER/RENAME ATTRIBUTE Like with tables, this also requires allowing the existence of composite types with zero attributes. reviewed by KaiGai Kohei
2010-09-26 13:41:03 +02:00
0);
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Add ALTER TYPE ... ADD/DROP/ALTER/RENAME ATTRIBUTE Like with tables, this also requires allowing the existence of composite types with zero attributes. reviewed by KaiGai Kohei
2010-09-26 13:41:03 +02:00
transform = coerce_to_target_type(pstate,
transform, exprType(transform),
targettype, targettypmod,
COERCION_ASSIGNMENT,
COERCE_IMPLICIT_CAST,
-1);
if (transform == NULL)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
errmsg("column \"%s\" cannot be cast automatically to type %s",
colName, format_type_be(targettype)),
Improve error message for ALTER COLUMN TYPE coercion failure. Per recent discussion, the error message for this was actually a trifle inaccurate, since it said "cannot be cast" which might be incorrect. Adjust that wording, and add a HINT suggesting that a USING clause might be needed.
2012-05-15 18:12:40 +02:00
errhint("Specify a USING expression to perform the conversion.")));
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Revise collation derivation method and expression-tree representation. 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.
2011-03-20 01:29:08 +01:00
/* Fix collations after all else */
assign_expr_collations(pstate, transform);
Add notion of a "transform function" that can simplify function calls. 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
2011-06-22 04:15:24 +02:00
/* Plan the expr now so we can accurately assess the need to rewrite. */
transform = (Node *) expression_planner((Expr *) transform);
Revise collation derivation method and expression-tree representation. 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.
2011-03-20 01:29:08 +01:00
Add ALTER TYPE ... ADD/DROP/ALTER/RENAME ATTRIBUTE Like with tables, this also requires allowing the existence of composite types with zero attributes. reviewed by KaiGai Kohei
2010-09-26 13:41:03 +02:00
/*
* Add a work queue item to make ATRewriteTable update the column
* contents.
*/
newval = (NewColumnValue *) palloc0(sizeof(NewColumnValue));
newval->attnum = attnum;
newval->expr = (Expr *) transform;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Add ALTER TYPE ... ADD/DROP/ALTER/RENAME ATTRIBUTE Like with tables, this also requires allowing the existence of composite types with zero attributes. reviewed by KaiGai Kohei
2010-09-26 13:41:03 +02:00
tab->newvals = lappend(tab->newvals, newval);
Teach ALTER TABLE .. SET DATA TYPE to avoid some table rewrites. 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
2011-02-12 14:27:55 +01:00
if (ATColumnChangeRequiresRewrite(transform, attnum))
tab->rewrite = true;
Add ALTER TYPE ... ADD/DROP/ALTER/RENAME ATTRIBUTE Like with tables, this also requires allowing the existence of composite types with zero attributes. reviewed by KaiGai Kohei
2010-09-26 13:41:03 +02:00
}
Remove collation information from TypeName, where it does not belong. 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.
2011-03-10 04:38:52 +01:00
else if (transform)
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
Message style tweaks
2011-07-04 23:01:35 +02:00
errmsg("\"%s\" is not a table",
RelationGetRelationName(rel))));
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Remove collation information from TypeName, where it does not belong. 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.
2011-03-10 04:38:52 +01:00
if (tab->relkind == RELKIND_COMPOSITE_TYPE ||
tab->relkind == RELKIND_FOREIGN_TABLE)
Add ALTER TYPE ... ADD/DROP/ALTER/RENAME ATTRIBUTE Like with tables, this also requires allowing the existence of composite types with zero attributes. reviewed by KaiGai Kohei
2010-09-26 13:41:03 +02:00
{
/*
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
* For composite types, do this check now. Tables will check it later
* when the table is being rewritten.
Add ALTER TYPE ... ADD/DROP/ALTER/RENAME ATTRIBUTE Like with tables, this also requires allowing the existence of composite types with zero attributes. reviewed by KaiGai Kohei
2010-09-26 13:41:03 +02:00
*/
Tweak find_composite_type_dependencies API a bit more. 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.
2011-02-11 14:47:38 +01:00
find_composite_type_dependencies(rel->rd_rel->reltype, rel, NULL);
Add ALTER TYPE ... ADD/DROP/ALTER/RENAME ATTRIBUTE Like with tables, this also requires allowing the existence of composite types with zero attributes. reviewed by KaiGai Kohei
2010-09-26 13:41:03 +02:00
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
ReleaseSysCache(tuple);
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* The recursion case is handled by ATSimpleRecursion. However, if we are
* told not to recurse, there had better not be any child tables; else the
* alter would put them out of step.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
if (recurse)
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATSimpleRecursion(wqueue, rel, cmd, recurse, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
else if (!recursing &&
Modify find_inheritance_children() and find_all_inheritors() to add the ability to lock relations as they scan pg_inherits, and to ignore any relations that have disappeared by the time we get lock on them. This makes uses of these functions safe against concurrent DROP operations on child tables: we will effectively ignore any just-dropped child, rather than possibly throwing an error as in recent bug report from Thomas Johansson (and similar past complaints). The behavior should not change otherwise, since the code was acquiring those same locks anyway, just a little bit later. An exception is LockTableCommand(), which is still behaving unsafely; but that seems to require some more discussion before we change it.
2009-05-12 05:11:02 +02:00
find_inheritance_children(RelationGetRelid(rel), NoLock) != NIL)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
ereport(ERROR,
(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
errmsg("type of inherited column \"%s\" must be changed in child tables too",
colName)));
Propagate ALTER TYPE operations to typed tables This adds RESTRICT/CASCADE flags to ALTER TYPE ... ADD/DROP/ALTER/ RENAME ATTRIBUTE to control whether to alter typed tables as well.
2010-11-23 21:50:17 +01:00
if (tab->relkind == RELKIND_COMPOSITE_TYPE)
ATTypedTableRecursion(wqueue, rel, cmd, lockmode);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
Teach ALTER TABLE .. SET DATA TYPE to avoid some table rewrites. 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
2011-02-12 14:27:55 +01:00
/*
Avoid a few more SET DATA TYPE table rewrites. 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
2011-02-15 05:17:35 +01:00
* When the data type of a column is changed, a rewrite might not be required
* if the new type is sufficiently identical to the old one, and the USING
* clause isn't trying to insert some other value. It's safe to skip the
* rewrite if the old type is binary coercible to the new type, or if the
* new type is an unconstrained domain over the old type. In the case of a
* constrained domain, we could get by with scanning the table and checking
* the constraint rather than actually rewriting it, but we don't currently
* try to do that.
Teach ALTER TABLE .. SET DATA TYPE to avoid some table rewrites. 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
2011-02-12 14:27:55 +01:00
*/
static bool
ATColumnChangeRequiresRewrite(Node *expr, AttrNumber varattno)
{
Assert(expr != NULL);
for (;;)
{
/* only one varno, so no need to check that */
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
if (IsA(expr, Var) &&((Var *) expr)->varattno == varattno)
Teach ALTER TABLE .. SET DATA TYPE to avoid some table rewrites. 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
2011-02-12 14:27:55 +01:00
return false;
else if (IsA(expr, RelabelType))
expr = (Node *) ((RelabelType *) expr)->arg;
Avoid a few more SET DATA TYPE table rewrites. 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
2011-02-15 05:17:35 +01:00
else if (IsA(expr, CoerceToDomain))
{
CoerceToDomain *d = (CoerceToDomain *) expr;
if (GetDomainConstraints(d->resulttype) != NIL)
return true;
expr = (Node *) d->arg;
}
Teach ALTER TABLE .. SET DATA TYPE to avoid some table rewrites. 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
2011-02-12 14:27:55 +01:00
else
return true;
}
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static void
ATExecAlterColumnType(AlteredTableInfo *tab, Relation rel,
Remove collation information from TypeName, where it does not belong. 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.
2011-03-10 04:38:52 +01:00
AlterTableCmd *cmd, LOCKMODE lockmode)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
Remove collation information from TypeName, where it does not belong. 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.
2011-03-10 04:38:52 +01:00
char *colName = cmd->name;
ColumnDef *def = (ColumnDef *) cmd->def;
TypeName *typeName = def->typeName;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
HeapTuple heapTup;
Form_pg_attribute attTup;
AttrNumber attnum;
HeapTuple typeTuple;
Form_pg_type tform;
Oid targettype;
Support type modifiers for user-defined types, and pull most knowledge about typmod representation for standard types out into type-specific typmod I/O functions. Teodor Sigaev, with some editorialization by Tom Lane.
2006-12-30 22:21:56 +01:00
int32 targettypmod;
Per-column collation support 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
2011-02-08 22:04:18 +01:00
Oid targetcollid;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Node *defaultexpr;
Relation attrelation;
Relation depRel;
ScanKeyData key[3];
SysScanDesc scan;
HeapTuple depTup;
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
attrelation = heap_open(AttributeRelationId, RowExclusiveLock);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Look up the target column */
heapTup = SearchSysCacheCopyAttName(RelationGetRelid(rel), colName);
if (!HeapTupleIsValid(heapTup)) /* shouldn't happen */
ereport(ERROR,
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
(errcode(ERRCODE_UNDEFINED_COLUMN),
errmsg("column \"%s\" of relation \"%s\" does not exist",
colName, RelationGetRelationName(rel))));
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
attTup = (Form_pg_attribute) GETSTRUCT(heapTup);
attnum = attTup->attnum;
/* Check for multiple ALTER TYPE on same column --- can't cope */
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
if (attTup->atttypid != tab->oldDesc->attrs[attnum - 1]->atttypid ||
attTup->atttypmod != tab->oldDesc->attrs[attnum - 1]->atttypmod)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot alter type of column \"%s\" twice",
colName)));
/* Look up the target type (should not fail, since prep found it) */
Remove collation information from TypeName, where it does not belong. 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.
2011-03-10 04:38:52 +01:00
typeTuple = typenameType(NULL, typeName, &targettypmod);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
tform = (Form_pg_type) GETSTRUCT(typeTuple);
targettype = HeapTupleGetOid(typeTuple);
Remove collation information from TypeName, where it does not belong. 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.
2011-03-10 04:38:52 +01:00
/* And the collation */
targetcollid = GetColumnDefCollation(NULL, def, targettype);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* If there is a default expression for the column, get it and ensure we
* can coerce it to the new datatype. (We must do this before changing
* the column type, because build_column_default itself will try to
* coerce, and will not issue the error message we want if it fails.)
In ALTER COLUMN TYPE, strip any implicit coercion operations appearing at the top level of the column's old default expression before adding an implicit coercion to the new column type. This seems to satisfy the principle of least surprise, as per discussion of bug #1290.
2004-10-22 19:20:05 +02:00
*
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
* We remove any implicit coercion steps at the top level of the old
* default expression; this has been agreed to satisfy the principle of
* least surprise. (The conversion to the new column type should act like
* it started from what the user sees as the stored expression, and the
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* implicit coercions aren't going to be shown.)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
if (attTup->atthasdef)
{
defaultexpr = build_column_default(rel, attnum);
Assert(defaultexpr);
In ALTER COLUMN TYPE, strip any implicit coercion operations appearing at the top level of the column's old default expression before adding an implicit coercion to the new column type. This seems to satisfy the principle of least surprise, as per discussion of bug #1290.
2004-10-22 19:20:05 +02:00
defaultexpr = strip_implicit_coercions(defaultexpr);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
defaultexpr = coerce_to_target_type(NULL, /* no UNKNOWN params */
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
defaultexpr, exprType(defaultexpr),
Support type modifiers for user-defined types, and pull most knowledge about typmod representation for standard types out into type-specific typmod I/O functions. Teodor Sigaev, with some editorialization by Tom Lane.
2006-12-30 22:21:56 +01:00
targettype, targettypmod,
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
COERCION_ASSIGNMENT,
Extend the parser location infrastructure to include a location field in most node types used in expression trees (both before and after parse analysis). This allows us to place an error cursor in many situations where we formerly could not, because the information wasn't available beyond the very first level of parse analysis. There's a fair amount of work still to be done to persuade individual ereport() calls to actually include an error location, but this gets the initdb-forcing part of the work out of the way; and the situation is already markedly better than before for complaints about unimplementable implicit casts, such as CASE and UNION constructs with incompatible alternative data types. Per my proposal of a few days ago.
2008-08-29 01:09:48 +02:00
COERCE_IMPLICIT_CAST,
-1);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (defaultexpr == NULL)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
errmsg("default for column \"%s\" cannot be cast automatically to type %s",
colName, format_type_be(targettype))));
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
else
defaultexpr = NULL;
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Find everything that depends on the column (constraints, indexes, etc),
* and record enough information to let us recreate the objects.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*
* The actual recreation does not happen here, but only after we have
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* performed all the individual ALTER TYPE operations. We have to save
* the info before executing ALTER TYPE, though, else the deparser will
* get confused.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
* There could be multiple entries for the same object, so we must check
* to ensure we process each one only once. Note: we assume that an index
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* that implements a constraint will not show a direct dependency on the
* column.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
depRel = heap_open(DependRelationId, RowExclusiveLock);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
ScanKeyInit(&key[0],
Anum_pg_depend_refclassid,
BTEqualStrategyNumber, F_OIDEQ,
First phase of project to use fixed OIDs for all system catalogs and indexes. Extend the macros in include/catalog/*.h to carry the info about hand-assigned OIDs, and adjust the genbki script and bootstrap code to make the relations actually get those OIDs. Remove the small number of RelOid_pg_foo macros that we had in favor of a complete set named like the catname.h and indexing.h macros. Next phase will get rid of internal use of names for looking up catalogs and indexes; but this completes the changes forcing an initdb, so it looks like a good place to commit. Along the way, I made the shared relations (pg_database etc) not be 'bootstrap' relations any more, so as to reduce the number of hardwired entries and simplify changing those relations in future. I'm not sure whether they ever really needed to be handled as bootstrap relations, but it seems to work fine to not do so now.
2005-04-14 03:38:22 +02:00
ObjectIdGetDatum(RelationRelationId));
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
ScanKeyInit(&key[1],
Anum_pg_depend_refobjid,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(RelationGetRelid(rel)));
ScanKeyInit(&key[2],
Anum_pg_depend_refobjsubid,
BTEqualStrategyNumber, F_INT4EQ,
Int32GetDatum((int32) attnum));
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
scan = systable_beginscan(depRel, DependReferenceIndexId, true,
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
SnapshotNow, 3, key);
while (HeapTupleIsValid(depTup = systable_getnext(scan)))
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
Form_pg_depend foundDep = (Form_pg_depend) GETSTRUCT(depTup);
ObjectAddress foundObject;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* We don't expect any PIN dependencies on columns */
if (foundDep->deptype == DEPENDENCY_PIN)
elog(ERROR, "cannot alter type of a pinned column");
foundObject.classId = foundDep->classid;
foundObject.objectId = foundDep->objid;
foundObject.objectSubId = foundDep->objsubid;
switch (getObjectClass(&foundObject))
{
case OCLASS_CLASS:
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
char relKind = get_rel_relkind(foundObject.objectId);
if (relKind == RELKIND_INDEX)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
Assert(foundObject.objectSubId == 0);
if (!list_member_oid(tab->changedIndexOids, foundObject.objectId))
{
tab->changedIndexOids = lappend_oid(tab->changedIndexOids,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
foundObject.objectId);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
tab->changedIndexDefs = lappend(tab->changedIndexDefs,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
pg_get_indexdef_string(foundObject.objectId));
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
else if (relKind == RELKIND_SEQUENCE)
{
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* This must be a SERIAL column's sequence. We need
* not do anything to it.
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
*/
Assert(foundObject.objectSubId == 0);
}
else
{
/* Not expecting any other direct dependencies... */
elog(ERROR, "unexpected object depending on column: %s",
getObjectDescription(&foundObject));
}
break;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
case OCLASS_CONSTRAINT:
Assert(foundObject.objectSubId == 0);
Fix ALTER COLUMN TYPE bug: it sometimes tried to drop UNIQUE or PRIMARY KEY constraints before FOREIGN KEY constraints that depended on them. Originally reported by Neil Conway on 29-Jun-2005. Patch by Nakano Yoshihisa.
2006-01-30 17:18:58 +01:00
if (!list_member_oid(tab->changedConstraintOids,
foundObject.objectId))
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
char *defstring = pg_get_constraintdef_string(foundObject.objectId);
Fix ALTER COLUMN TYPE bug: it sometimes tried to drop UNIQUE or PRIMARY KEY constraints before FOREIGN KEY constraints that depended on them. Originally reported by Neil Conway on 29-Jun-2005. Patch by Nakano Yoshihisa.
2006-01-30 17:18:58 +01:00
/*
* Put NORMAL dependencies at the front of the list and
* AUTO dependencies at the back. This makes sure that
* foreign-key constraints depending on this column will
* be dropped before unique or primary-key constraints of
* the column; which we must have because the FK
* constraints depend on the indexes belonging to the
* unique constraints.
*/
if (foundDep->deptype == DEPENDENCY_NORMAL)
{
tab->changedConstraintOids =
lcons_oid(foundObject.objectId,
tab->changedConstraintOids);
tab->changedConstraintDefs =
lcons(defstring,
tab->changedConstraintDefs);
}
else
{
tab->changedConstraintOids =
lappend_oid(tab->changedConstraintOids,
foundObject.objectId);
tab->changedConstraintDefs =
lappend(tab->changedConstraintDefs,
defstring);
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
break;
case OCLASS_REWRITE:
/* XXX someday see if we can cope with revising views */
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot alter type of a column used by a view or rule"),
errdetail("%s depends on column \"%s\"",
getObjectDescription(&foundObject),
colName)));
break;
Throw an appropriate error if ALTER COLUMN TYPE finds a dependent trigger. Actually making this case work, if the column is used in the trigger's WHEN condition, will take some new code that probably isn't appropriate to back-patch. For now, just throw a FEATURE_NOT_SUPPORTED error rather than allowing control to reach the "unexpected object" case. Per bug #5688 from Daniel Grace. Back-patch to 9.0 where the possibility of such a dependency was introduced.
2010-10-03 00:21:41 +02:00
case OCLASS_TRIGGER:
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
Throw an appropriate error if ALTER COLUMN TYPE finds a dependent trigger. Actually making this case work, if the column is used in the trigger's WHEN condition, will take some new code that probably isn't appropriate to back-patch. For now, just throw a FEATURE_NOT_SUPPORTED error rather than allowing control to reach the "unexpected object" case. Per bug #5688 from Daniel Grace. Back-patch to 9.0 where the possibility of such a dependency was introduced.
2010-10-03 00:21:41 +02:00
/*
* A trigger can depend on a column because the column is
* specified as an update target, or because the column is
* used in the trigger's WHEN condition. The first case would
* not require any extra work, but the second case would
* require updating the WHEN expression, which will take a
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
* significant amount of new code. Since we can't easily tell
Throw an appropriate error if ALTER COLUMN TYPE finds a dependent trigger. Actually making this case work, if the column is used in the trigger's WHEN condition, will take some new code that probably isn't appropriate to back-patch. For now, just throw a FEATURE_NOT_SUPPORTED error rather than allowing control to reach the "unexpected object" case. Per bug #5688 from Daniel Grace. Back-patch to 9.0 where the possibility of such a dependency was introduced.
2010-10-03 00:21:41 +02:00
* which case applies, we punt for both. FIXME someday.
*/
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot alter type of a column used in a trigger definition"),
errdetail("%s depends on column \"%s\"",
getObjectDescription(&foundObject),
colName)));
break;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
case OCLASS_DEFAULT:
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Ignore the column's default expression, since we will fix
* it below.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
Assert(defaultexpr);
break;
case OCLASS_PROC:
case OCLASS_TYPE:
case OCLASS_CAST:
DDL support for collations - 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
2011-02-12 14:54:13 +01:00
case OCLASS_COLLATION:
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
case OCLASS_CONVERSION:
case OCLASS_LANGUAGE:
Add large object access control. A new system catalog pg_largeobject_metadata manages ownership and access privileges of large objects. KaiGai Kohei, reviewed by Jaime Casanova.
2009-12-11 04:34:57 +01:00
case OCLASS_LARGEOBJECT:
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
case OCLASS_OPERATOR:
case OCLASS_OPCLASS:
Tsearch2 functionality migrates to core. The bulk of this work is by Oleg Bartunov and Teodor Sigaev, but I did a lot of editorializing, so anything that's broken is probably my fault. Documentation is nonexistent as yet, but let's land the patch so we can get some portability testing done.
2007-08-21 03:11:32 +02:00
case OCLASS_OPFAMILY:
Fix some omissions in the dependency-object-class support for SQL/MED objects. Main problem found by Muhammad Aqeel, some cosmetic additions by me.
2009-08-07 17:27:56 +02:00
case OCLASS_AMOP:
case OCLASS_AMPROC:
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
case OCLASS_SCHEMA:
Tsearch2 functionality migrates to core. The bulk of this work is by Oleg Bartunov and Teodor Sigaev, but I did a lot of editorializing, so anything that's broken is probably my fault. Documentation is nonexistent as yet, but let's land the patch so we can get some portability testing done.
2007-08-21 03:11:32 +02:00
case OCLASS_TSPARSER:
case OCLASS_TSDICT:
case OCLASS_TSTEMPLATE:
case OCLASS_TSCONFIG:
Fix some omissions in the dependency-object-class support for SQL/MED objects. Main problem found by Muhammad Aqeel, some cosmetic additions by me.
2009-08-07 17:27:56 +02:00
case OCLASS_ROLE:
case OCLASS_DATABASE:
case OCLASS_TBLSPACE:
case OCLASS_FDW:
case OCLASS_FOREIGN_SERVER:
case OCLASS_USER_MAPPING:
Create an ALTER DEFAULT PRIVILEGES command, which allows users to adjust the privileges that will be applied to subsequently-created objects. Such adjustments are always per owning role, and can be restricted to objects created in particular schemas too. A notable benefit is that users can override the traditional default privilege settings, eg, the PUBLIC EXECUTE privilege traditionally granted by default for functions. Petr Jelinek
2009-10-05 21:24:49 +02:00
case OCLASS_DEFACL:
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
2011-02-08 22:08:41 +01:00
case OCLASS_EXTENSION:
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* We don't expect any of these sorts of objects to depend on
* a column.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
elog(ERROR, "unexpected object depending on column: %s",
getObjectDescription(&foundObject));
break;
default:
elog(ERROR, "unrecognized object class: %u",
foundObject.classId);
}
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
systable_endscan(scan);
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* Now scan for dependencies of this column on other things. The only
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* thing we should find is the dependency on the column datatype, which we
Make a code-cleanup pass over the collations patch. 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().
2011-04-22 23:43:18 +02:00
* want to remove, and possibly a collation dependency.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
ScanKeyInit(&key[0],
Anum_pg_depend_classid,
BTEqualStrategyNumber, F_OIDEQ,
First phase of project to use fixed OIDs for all system catalogs and indexes. Extend the macros in include/catalog/*.h to carry the info about hand-assigned OIDs, and adjust the genbki script and bootstrap code to make the relations actually get those OIDs. Remove the small number of RelOid_pg_foo macros that we had in favor of a complete set named like the catname.h and indexing.h macros. Next phase will get rid of internal use of names for looking up catalogs and indexes; but this completes the changes forcing an initdb, so it looks like a good place to commit. Along the way, I made the shared relations (pg_database etc) not be 'bootstrap' relations any more, so as to reduce the number of hardwired entries and simplify changing those relations in future. I'm not sure whether they ever really needed to be handled as bootstrap relations, but it seems to work fine to not do so now.
2005-04-14 03:38:22 +02:00
ObjectIdGetDatum(RelationRelationId));
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
ScanKeyInit(&key[1],
Anum_pg_depend_objid,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(RelationGetRelid(rel)));
ScanKeyInit(&key[2],
Anum_pg_depend_objsubid,
BTEqualStrategyNumber, F_INT4EQ,
Int32GetDatum((int32) attnum));
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
scan = systable_beginscan(depRel, DependDependerIndexId, true,
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
SnapshotNow, 3, key);
while (HeapTupleIsValid(depTup = systable_getnext(scan)))
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
Form_pg_depend foundDep = (Form_pg_depend) GETSTRUCT(depTup);
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (foundDep->deptype != DEPENDENCY_NORMAL)
elog(ERROR, "found unexpected dependency type '%c'",
foundDep->deptype);
DDL support for collations - 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
2011-02-12 14:54:13 +01:00
if (!(foundDep->refclassid == TypeRelationId &&
foundDep->refobjid == attTup->atttypid) &&
!(foundDep->refclassid == CollationRelationId &&
foundDep->refobjid == attTup->attcollation))
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
elog(ERROR, "found unexpected dependency for column");
simple_heap_delete(depRel, &depTup->t_self);
}
systable_endscan(scan);
heap_close(depRel, RowExclusiveLock);
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
/*
Make a code-cleanup pass over the collations patch. 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().
2011-04-22 23:43:18 +02:00
* Here we go --- change the recorded column type and collation. (Note
* heapTup is a copy of the syscache entry, so okay to scribble on.)
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
attTup->atttypid = targettype;
Support type modifiers for user-defined types, and pull most knowledge about typmod representation for standard types out into type-specific typmod I/O functions. Teodor Sigaev, with some editorialization by Tom Lane.
2006-12-30 22:21:56 +01:00
attTup->atttypmod = targettypmod;
Per-column collation support 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
2011-02-08 22:04:18 +01:00
attTup->attcollation = targetcollid;
Make backend header files C++ safe This alters various incidental uses of C++ key words to use other similar identifiers, so that a C++ compiler won't choke outright. You still (probably) need extern "C" { }; around the inclusion of backend headers. based on a patch by Kurt Harriman <harriman@acm.org> Also add a script cpluspluscheck to check for C++ compatibility in the future. As of right now, this passes without error for me.
2009-07-16 08:33:46 +02:00
attTup->attndims = list_length(typeName->arrayBounds);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
attTup->attlen = tform->typlen;
attTup->attbyval = tform->typbyval;
attTup->attalign = tform->typalign;
attTup->attstorage = tform->typstorage;
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
ReleaseSysCache(typeTuple);
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
simple_heap_update(attrelation, &heapTup->t_self, heapTup);
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* keep system catalog indexes current */
CatalogUpdateIndexes(attrelation, heapTup);
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
heap_close(attrelation, RowExclusiveLock);
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
Make a code-cleanup pass over the collations patch. 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().
2011-04-22 23:43:18 +02:00
/* Install dependencies on new datatype and collation */
add_column_datatype_dependency(RelationGetRelid(rel), attnum, targettype);
add_column_collation_dependency(RelationGetRelid(rel), attnum, targetcollid);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Drop any pg_statistic entry for the column, since it's now wrong type
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
*/
Rearrange order of operations in heap_drop_with_catalog and index_drop so that we close and flush the doomed relation's relcache entry before we start to delete the underlying catalog rows, rather than afterwards. For awhile yesterday I thought that an unexpected relcache entry rebuild partway through this sequence might explain the infrequent parallel regression failures we were chasing. It doesn't, mainly because there's no CommandCounterIncrement in the sequence and so the deletions aren't "really" done yet. But it sure seems like trouble waiting to happen.
2004-08-28 23:05:26 +02:00
RemoveStatistics(RelationGetRelid(rel), attnum);
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
InvokeObjectPostAlterHook(RelationRelationId,
RelationGetRelid(rel), attnum);
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Update the default, if present, by brute force --- remove and re-add
* the default. Probably unsafe to take shortcuts, since the new version
* may well have additional dependencies. (It's okay to do this now,
* rather than after other ALTER TYPE commands, since the default won't
* depend on other column types.)
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (defaultexpr)
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
{
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Must make new row visible since it will be updated again */
CommandCounterIncrement();
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* We use RESTRICT here for safety, but at present we do not expect
* anything to depend on the default.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
Classify DROP operations by whether or not they are user-initiated. This doesn't do anything useful just yet, but is intended as supporting infrastructure for allowing sepgsql to sensibly check DROP permissions. KaiGai Kohei and Robert Haas
2012-01-26 15:24:54 +01:00
RemoveAttrDefault(RelationGetRelid(rel), attnum, DROP_RESTRICT, true,
true);
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
StoreAttrDefault(rel, attnum, defaultexpr, true);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Cleanup */
heap_freetuple(heapTup);
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
}
Allow per-column foreign data wrapper options. Shigeru Hanada, with fairly minor editing by me.
2011-08-05 19:24:03 +02:00
static void
ATExecAlterColumnGenericOptions(Relation rel,
const char *colName,
List *options,
LOCKMODE lockmode)
{
Relation ftrel;
Relation attrel;
ForeignServer *server;
ForeignDataWrapper *fdw;
HeapTuple tuple;
HeapTuple newtuple;
bool isnull;
Datum repl_val[Natts_pg_attribute];
bool repl_null[Natts_pg_attribute];
bool repl_repl[Natts_pg_attribute];
Datum datum;
Form_pg_foreign_table fttableform;
Form_pg_attribute atttableform;
if (options == NIL)
return;
/* First, determine FDW validator associated to the foreign table. */
ftrel = heap_open(ForeignTableRelationId, AccessShareLock);
tuple = SearchSysCache1(FOREIGNTABLEREL, rel->rd_id);
if (!HeapTupleIsValid(tuple))
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_OBJECT),
errmsg("foreign table \"%s\" does not exist",
RelationGetRelationName(rel))));
fttableform = (Form_pg_foreign_table) GETSTRUCT(tuple);
server = GetForeignServer(fttableform->ftserver);
fdw = GetForeignDataWrapper(server->fdwid);
heap_close(ftrel, AccessShareLock);
ReleaseSysCache(tuple);
attrel = heap_open(AttributeRelationId, RowExclusiveLock);
tuple = SearchSysCacheAttName(RelationGetRelid(rel), colName);
if (!HeapTupleIsValid(tuple))
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_COLUMN),
errmsg("column \"%s\" of relation \"%s\" does not exist",
colName, RelationGetRelationName(rel))));
/* Prevent them from altering a system attribute */
atttableform = (Form_pg_attribute) GETSTRUCT(tuple);
if (atttableform->attnum <= 0)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot alter system column \"%s\"", colName)));
/* Initialize buffers for new tuple values */
memset(repl_val, 0, sizeof(repl_val));
memset(repl_null, false, sizeof(repl_null));
memset(repl_repl, false, sizeof(repl_repl));
/* Extract the current options */
datum = SysCacheGetAttr(ATTNAME,
tuple,
Anum_pg_attribute_attfdwoptions,
&isnull);
if (isnull)
datum = PointerGetDatum(NULL);
/* Transform the options */
datum = transformGenericOptions(AttributeRelationId,
datum,
options,
fdw->fdwvalidator);
if (PointerIsValid(DatumGetPointer(datum)))
repl_val[Anum_pg_attribute_attfdwoptions - 1] = datum;
else
repl_null[Anum_pg_attribute_attfdwoptions - 1] = true;
repl_repl[Anum_pg_attribute_attfdwoptions - 1] = true;
/* Everything looks good - update the tuple */
newtuple = heap_modify_tuple(tuple, RelationGetDescr(attrel),
repl_val, repl_null, repl_repl);
simple_heap_update(attrel, &newtuple->t_self, newtuple);
CatalogUpdateIndexes(attrel, newtuple);
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
InvokeObjectPostAlterHook(RelationRelationId,
RelationGetRelid(rel),
atttableform->attnum);
ReleaseSysCache(tuple);
Allow per-column foreign data wrapper options. Shigeru Hanada, with fairly minor editing by me.
2011-08-05 19:24:03 +02:00
heap_close(attrel, RowExclusiveLock);
heap_freetuple(newtuple);
}
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
/*
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
* Cleanup after we've finished all the ALTER TYPE operations for a
* particular relation. We have to drop and recreate all the indexes
* and constraints that depend on the altered columns.
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static void
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATPostAlterTypeCleanup(List **wqueue, AlteredTableInfo *tab, LOCKMODE lockmode)
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
{
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
ObjectAddress obj;
Avoid index rebuild for no-rewrite ALTER TABLE .. ALTER TYPE. Noah Misch. Review and minor cosmetic changes by me.
2011-07-18 17:02:48 +02:00
ListCell *def_item;
ListCell *oid_item;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Re-parse the index and constraint definitions, and attach them to the
* appropriate work queue entries. We do this before dropping because in
* the case of a FOREIGN KEY constraint, we might not yet have exclusive
* lock on the table the constraint is attached to, and we need to get
* that before dropping. It's safe because the parser won't actually look
* at the catalogs to detect the existing entry.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
Avoid index rebuild for no-rewrite ALTER TABLE .. ALTER TYPE. Noah Misch. Review and minor cosmetic changes by me.
2011-07-18 17:02:48 +02:00
forboth(oid_item, tab->changedConstraintOids,
def_item, tab->changedConstraintDefs)
ATPostAlterTypeParse(lfirst_oid(oid_item), (char *) lfirst(def_item),
wqueue, lockmode, tab->rewrite);
forboth(oid_item, tab->changedIndexOids,
def_item, tab->changedIndexDefs)
ATPostAlterTypeParse(lfirst_oid(oid_item), (char *) lfirst(def_item),
wqueue, lockmode, tab->rewrite);
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Now we can drop the existing constraints and indexes --- constraints
Fix ALTER COLUMN TYPE bug: it sometimes tried to drop UNIQUE or PRIMARY KEY constraints before FOREIGN KEY constraints that depended on them. Originally reported by Neil Conway on 29-Jun-2005. Patch by Nakano Yoshihisa.
2006-01-30 17:18:58 +01:00
* first, since some of them might depend on the indexes. In fact, we
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* have to delete FOREIGN KEY constraints before UNIQUE constraints, but
* we already ordered the constraint list to ensure that would happen. It
* should be okay to use DROP_RESTRICT here, since nothing else should be
* depending on these objects.
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
*/
Avoid index rebuild for no-rewrite ALTER TABLE .. ALTER TYPE. Noah Misch. Review and minor cosmetic changes by me.
2011-07-18 17:02:48 +02:00
foreach(oid_item, tab->changedConstraintOids)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
obj.classId = ConstraintRelationId;
Avoid index rebuild for no-rewrite ALTER TABLE .. ALTER TYPE. Noah Misch. Review and minor cosmetic changes by me.
2011-07-18 17:02:48 +02:00
obj.objectId = lfirst_oid(oid_item);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
obj.objectSubId = 0;
Classify DROP operations by whether or not they are user-initiated. This doesn't do anything useful just yet, but is intended as supporting infrastructure for allowing sepgsql to sensibly check DROP permissions. KaiGai Kohei and Robert Haas
2012-01-26 15:24:54 +01:00
performDeletion(&obj, DROP_RESTRICT, PERFORM_DELETION_INTERNAL);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
Avoid index rebuild for no-rewrite ALTER TABLE .. ALTER TYPE. Noah Misch. Review and minor cosmetic changes by me.
2011-07-18 17:02:48 +02:00
foreach(oid_item, tab->changedIndexOids)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
obj.classId = RelationRelationId;
Avoid index rebuild for no-rewrite ALTER TABLE .. ALTER TYPE. Noah Misch. Review and minor cosmetic changes by me.
2011-07-18 17:02:48 +02:00
obj.objectId = lfirst_oid(oid_item);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
obj.objectSubId = 0;
Classify DROP operations by whether or not they are user-initiated. This doesn't do anything useful just yet, but is intended as supporting infrastructure for allowing sepgsql to sensibly check DROP permissions. KaiGai Kohei and Robert Haas
2012-01-26 15:24:54 +01:00
performDeletion(&obj, DROP_RESTRICT, PERFORM_DELETION_INTERNAL);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* The objects will get recreated during subsequent passes over the work
* queue.
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
*/
}
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static void
Avoid index rebuild for no-rewrite ALTER TABLE .. ALTER TYPE. Noah Misch. Review and minor cosmetic changes by me.
2011-07-18 17:02:48 +02:00
ATPostAlterTypeParse(Oid oldId, char *cmd,
List **wqueue, LOCKMODE lockmode, bool rewrite)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
List *raw_parsetree_list;
List *querytree_list;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *list_item;
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
/*
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* We expect that we will get only ALTER TABLE and CREATE INDEX
* statements. Hence, there is no need to pass them through
* parse_analyze() or the rewriter, but instead we need to pass them
* through parse_utilcmd.c to make them ready for execution.
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
raw_parsetree_list = raw_parser(cmd);
querytree_list = NIL;
foreach(list_item, raw_parsetree_list)
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
{
Separate parse-analysis for utility commands out of parser/analyze.c (which now deals only in optimizable statements), and put that code into a new file parser/parse_utilcmd.c. This helps clarify and enforce the design rule that utility statements shouldn't be processed during the regular parse analysis phase; all interpretation of their meaning should happen after they are given to ProcessUtility to execute. (We need this because we don't retain any locks for a utility statement that's in a plan cache, nor have any way to detect that it's stale.) We are also able to simplify the API for parse_analyze() and related routines, because they will now always return exactly one Query structure. In passing, fix bug #3403 concerning trying to add a serial column to an existing temp table (this is largely Heikki's work, but we needed all that restructuring to make it safe).
2007-06-24 00:12:52 +02:00
Node *stmt = (Node *) lfirst(list_item);
if (IsA(stmt, IndexStmt))
querytree_list = lappend(querytree_list,
transformIndexStmt((IndexStmt *) stmt,
cmd));
else if (IsA(stmt, AlterTableStmt))
querytree_list = list_concat(querytree_list,
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
transformAlterTableStmt((AlterTableStmt *) stmt,
cmd));
Separate parse-analysis for utility commands out of parser/analyze.c (which now deals only in optimizable statements), and put that code into a new file parser/parse_utilcmd.c. This helps clarify and enforce the design rule that utility statements shouldn't be processed during the regular parse analysis phase; all interpretation of their meaning should happen after they are given to ProcessUtility to execute. (We need this because we don't retain any locks for a utility statement that's in a plan cache, nor have any way to detect that it's stale.) We are also able to simplify the API for parse_analyze() and related routines, because they will now always return exactly one Query structure. In passing, fix bug #3403 concerning trying to add a serial column to an existing temp table (this is largely Heikki's work, but we needed all that restructuring to make it safe).
2007-06-24 00:12:52 +02:00
else
querytree_list = lappend(querytree_list, stmt);
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
}
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Attach each generated command to the proper place in the work queue.
* Note this could result in creation of entirely new work-queue entries.
Fix handling of inherited check constraints in ALTER COLUMN TYPE. This case got broken in 8.4 by the addition of an error check that complains if ALTER TABLE ONLY is used on a table that has children. We do use ONLY for this situation, but it's okay because the necessary recursion occurs at a higher level. So we need to have a separate flag to suppress recursion without making the error check. Reported and patched by Pavan Deolasee, with some editorial adjustments by me. Back-patch to 8.4, since this is a regression of functionality that worked in earlier branches.
2012-11-05 19:36:16 +01:00
*
* Also note that we have to tweak the command subtypes, because it turns
* out that re-creation of indexes and constraints has to act a bit
* differently from initial creation.
The contents of command.c, creatinh.c, define.c, remove.c and rename.c have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
2002-04-15 07:22:04 +02:00
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
foreach(list_item, querytree_list)
{
Separate parse-analysis for utility commands out of parser/analyze.c (which now deals only in optimizable statements), and put that code into a new file parser/parse_utilcmd.c. This helps clarify and enforce the design rule that utility statements shouldn't be processed during the regular parse analysis phase; all interpretation of their meaning should happen after they are given to ProcessUtility to execute. (We need this because we don't retain any locks for a utility statement that's in a plan cache, nor have any way to detect that it's stale.) We are also able to simplify the API for parse_analyze() and related routines, because they will now always return exactly one Query structure. In passing, fix bug #3403 concerning trying to add a serial column to an existing temp table (this is largely Heikki's work, but we needed all that restructuring to make it safe).
2007-06-24 00:12:52 +02:00
Node *stm = (Node *) lfirst(list_item);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Relation rel;
AlteredTableInfo *tab;
Separate parse-analysis for utility commands out of parser/analyze.c (which now deals only in optimizable statements), and put that code into a new file parser/parse_utilcmd.c. This helps clarify and enforce the design rule that utility statements shouldn't be processed during the regular parse analysis phase; all interpretation of their meaning should happen after they are given to ProcessUtility to execute. (We need this because we don't retain any locks for a utility statement that's in a plan cache, nor have any way to detect that it's stale.) We are also able to simplify the API for parse_analyze() and related routines, because they will now always return exactly one Query structure. In passing, fix bug #3403 concerning trying to add a serial column to an existing temp table (this is largely Heikki's work, but we needed all that restructuring to make it safe).
2007-06-24 00:12:52 +02:00
switch (nodeTag(stm))
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
case T_IndexStmt:
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
{
Separate parse-analysis for utility commands out of parser/analyze.c (which now deals only in optimizable statements), and put that code into a new file parser/parse_utilcmd.c. This helps clarify and enforce the design rule that utility statements shouldn't be processed during the regular parse analysis phase; all interpretation of their meaning should happen after they are given to ProcessUtility to execute. (We need this because we don't retain any locks for a utility statement that's in a plan cache, nor have any way to detect that it's stale.) We are also able to simplify the API for parse_analyze() and related routines, because they will now always return exactly one Query structure. In passing, fix bug #3403 concerning trying to add a serial column to an existing temp table (this is largely Heikki's work, but we needed all that restructuring to make it safe).
2007-06-24 00:12:52 +02:00
IndexStmt *stmt = (IndexStmt *) stm;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
AlterTableCmd *newcmd;
Avoid index rebuild for no-rewrite ALTER TABLE .. ALTER TYPE. Noah Misch. Review and minor cosmetic changes by me.
2011-07-18 17:02:48 +02:00
if (!rewrite)
TryReuseIndex(oldId, stmt);
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
rel = relation_openrv(stmt->relation, lockmode);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
tab = ATGetQueueEntry(wqueue, rel);
newcmd = makeNode(AlterTableCmd);
newcmd->subtype = AT_ReAddIndex;
newcmd->def = (Node *) stmt;
tab->subcmds[AT_PASS_OLD_INDEX] =
lappend(tab->subcmds[AT_PASS_OLD_INDEX], newcmd);
relation_close(rel, NoLock);
break;
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
case T_AlterTableStmt:
{
Separate parse-analysis for utility commands out of parser/analyze.c (which now deals only in optimizable statements), and put that code into a new file parser/parse_utilcmd.c. This helps clarify and enforce the design rule that utility statements shouldn't be processed during the regular parse analysis phase; all interpretation of their meaning should happen after they are given to ProcessUtility to execute. (We need this because we don't retain any locks for a utility statement that's in a plan cache, nor have any way to detect that it's stale.) We are also able to simplify the API for parse_analyze() and related routines, because they will now always return exactly one Query structure. In passing, fix bug #3403 concerning trying to add a serial column to an existing temp table (this is largely Heikki's work, but we needed all that restructuring to make it safe).
2007-06-24 00:12:52 +02:00
AlterTableStmt *stmt = (AlterTableStmt *) stm;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
ListCell *lcmd;
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
rel = relation_openrv(stmt->relation, lockmode);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
tab = ATGetQueueEntry(wqueue, rel);
foreach(lcmd, stmt->cmds)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
AlterTableCmd *cmd = (AlterTableCmd *) lfirst(lcmd);
ALTER TABLE: skip FK validation when it's safe to do so We already skip rewriting the table in these cases, but we still force a whole table scan to validate the data. This can be skipped, and thus we can make the whole ALTER TABLE operation just do some catalog touches instead of scanning the table, when these two conditions hold: (a) Old and new pg_constraint.conpfeqop match exactly. This is actually stronger than needed; we could loosen things by way of operator families, but it'd require a lot more effort. (b) The functions, if any, implementing a cast from the foreign type to the primary opcintype are the same. For this purpose, we can consider a binary coercion equivalent to an exact type match. When the opcintype is polymorphic, require that the old and new foreign types match exactly. (Since ri_triggers.c does use the executor, the stronger check for polymorphic types is no mere future-proofing. However, no core type exercises its necessity.) Author: Noah Misch Committer's note: catalog version bumped due to change of the Constraint node. I can't actually find any way to have such a node in a stored rule, but given that we have "out" support for them, better be safe.
2012-02-27 22:28:00 +01:00
Constraint *con;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
switch (cmd->subtype)
{
case AT_AddIndex:
Avoid index rebuild for no-rewrite ALTER TABLE .. ALTER TYPE. Noah Misch. Review and minor cosmetic changes by me.
2011-07-18 17:02:48 +02:00
Assert(IsA(cmd->def, IndexStmt));
if (!rewrite)
TryReuseIndex(get_constraint_index(oldId),
(IndexStmt *) cmd->def);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
cmd->subtype = AT_ReAddIndex;
tab->subcmds[AT_PASS_OLD_INDEX] =
lappend(tab->subcmds[AT_PASS_OLD_INDEX], cmd);
break;
case AT_AddConstraint:
ALTER TABLE: skip FK validation when it's safe to do so We already skip rewriting the table in these cases, but we still force a whole table scan to validate the data. This can be skipped, and thus we can make the whole ALTER TABLE operation just do some catalog touches instead of scanning the table, when these two conditions hold: (a) Old and new pg_constraint.conpfeqop match exactly. This is actually stronger than needed; we could loosen things by way of operator families, but it'd require a lot more effort. (b) The functions, if any, implementing a cast from the foreign type to the primary opcintype are the same. For this purpose, we can consider a binary coercion equivalent to an exact type match. When the opcintype is polymorphic, require that the old and new foreign types match exactly. (Since ri_triggers.c does use the executor, the stronger check for polymorphic types is no mere future-proofing. However, no core type exercises its necessity.) Author: Noah Misch Committer's note: catalog version bumped due to change of the Constraint node. I can't actually find any way to have such a node in a stored rule, but given that we have "out" support for them, better be safe.
2012-02-27 22:28:00 +01:00
Assert(IsA(cmd->def, Constraint));
con = (Constraint *) cmd->def;
/* rewriting neither side of a FK */
if (con->contype == CONSTR_FOREIGN &&
!rewrite && !tab->rewrite)
TryReuseForeignKey(oldId, con);
Fix handling of inherited check constraints in ALTER COLUMN TYPE. This case got broken in 8.4 by the addition of an error check that complains if ALTER TABLE ONLY is used on a table that has children. We do use ONLY for this situation, but it's okay because the necessary recursion occurs at a higher level. So we need to have a separate flag to suppress recursion without making the error check. Reported and patched by Pavan Deolasee, with some editorial adjustments by me. Back-patch to 8.4, since this is a regression of functionality that worked in earlier branches.
2012-11-05 19:36:16 +01:00
cmd->subtype = AT_ReAddConstraint;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
tab->subcmds[AT_PASS_OLD_CONSTR] =
lappend(tab->subcmds[AT_PASS_OLD_CONSTR], cmd);
break;
default:
elog(ERROR, "unexpected statement type: %d",
(int) cmd->subtype);
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
relation_close(rel, NoLock);
break;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
default:
elog(ERROR, "unexpected statement type: %d",
Separate parse-analysis for utility commands out of parser/analyze.c (which now deals only in optimizable statements), and put that code into a new file parser/parse_utilcmd.c. This helps clarify and enforce the design rule that utility statements shouldn't be processed during the regular parse analysis phase; all interpretation of their meaning should happen after they are given to ProcessUtility to execute. (We need this because we don't retain any locks for a utility statement that's in a plan cache, nor have any way to detect that it's stale.) We are also able to simplify the API for parse_analyze() and related routines, because they will now always return exactly one Query structure. In passing, fix bug #3403 concerning trying to add a serial column to an existing temp table (this is largely Heikki's work, but we needed all that restructuring to make it safe).
2007-06-24 00:12:52 +02:00
(int) nodeTag(stm));
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
}
}
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
}
Avoid index rebuild for no-rewrite ALTER TABLE .. ALTER TYPE. Noah Misch. Review and minor cosmetic changes by me.
2011-07-18 17:02:48 +02:00
/*
* Subroutine for ATPostAlterTypeParse(). Calls out to CheckIndexCompatible()
* for the real analysis, then mutates the IndexStmt based on that verdict.
ALTER TABLE: skip FK validation when it's safe to do so We already skip rewriting the table in these cases, but we still force a whole table scan to validate the data. This can be skipped, and thus we can make the whole ALTER TABLE operation just do some catalog touches instead of scanning the table, when these two conditions hold: (a) Old and new pg_constraint.conpfeqop match exactly. This is actually stronger than needed; we could loosen things by way of operator families, but it'd require a lot more effort. (b) The functions, if any, implementing a cast from the foreign type to the primary opcintype are the same. For this purpose, we can consider a binary coercion equivalent to an exact type match. When the opcintype is polymorphic, require that the old and new foreign types match exactly. (Since ri_triggers.c does use the executor, the stronger check for polymorphic types is no mere future-proofing. However, no core type exercises its necessity.) Author: Noah Misch Committer's note: catalog version bumped due to change of the Constraint node. I can't actually find any way to have such a node in a stored rule, but given that we have "out" support for them, better be safe.
2012-02-27 22:28:00 +01:00
*/
Avoid index rebuild for no-rewrite ALTER TABLE .. ALTER TYPE. Noah Misch. Review and minor cosmetic changes by me.
2011-07-18 17:02:48 +02:00
static void
TryReuseIndex(Oid oldId, IndexStmt *stmt)
{
if (CheckIndexCompatible(oldId,
stmt->relation,
stmt->accessMethod,
stmt->indexParams,
stmt->excludeOpNames))
{
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
Relation irel = index_open(oldId, NoLock);
Avoid index rebuild for no-rewrite ALTER TABLE .. ALTER TYPE. Noah Misch. Review and minor cosmetic changes by me.
2011-07-18 17:02:48 +02:00
stmt->oldNode = irel->rd_node.relNode;
index_close(irel, NoLock);
}
}
ALTER TABLE: skip FK validation when it's safe to do so We already skip rewriting the table in these cases, but we still force a whole table scan to validate the data. This can be skipped, and thus we can make the whole ALTER TABLE operation just do some catalog touches instead of scanning the table, when these two conditions hold: (a) Old and new pg_constraint.conpfeqop match exactly. This is actually stronger than needed; we could loosen things by way of operator families, but it'd require a lot more effort. (b) The functions, if any, implementing a cast from the foreign type to the primary opcintype are the same. For this purpose, we can consider a binary coercion equivalent to an exact type match. When the opcintype is polymorphic, require that the old and new foreign types match exactly. (Since ri_triggers.c does use the executor, the stronger check for polymorphic types is no mere future-proofing. However, no core type exercises its necessity.) Author: Noah Misch Committer's note: catalog version bumped due to change of the Constraint node. I can't actually find any way to have such a node in a stored rule, but given that we have "out" support for them, better be safe.
2012-02-27 22:28:00 +01:00
/*
* Subroutine for ATPostAlterTypeParse().
*
* Stash the old P-F equality operator into the Constraint node, for possible
* use by ATAddForeignKeyConstraint() in determining whether revalidation of
* this constraint can be skipped.
*/
static void
TryReuseForeignKey(Oid oldId, Constraint *con)
{
HeapTuple tup;
Datum adatum;
bool isNull;
ArrayType *arr;
Oid *rawarr;
int numkeys;
int i;
Assert(con->contype == CONSTR_FOREIGN);
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
Assert(con->old_conpfeqop == NIL); /* already prepared this node */
ALTER TABLE: skip FK validation when it's safe to do so We already skip rewriting the table in these cases, but we still force a whole table scan to validate the data. This can be skipped, and thus we can make the whole ALTER TABLE operation just do some catalog touches instead of scanning the table, when these two conditions hold: (a) Old and new pg_constraint.conpfeqop match exactly. This is actually stronger than needed; we could loosen things by way of operator families, but it'd require a lot more effort. (b) The functions, if any, implementing a cast from the foreign type to the primary opcintype are the same. For this purpose, we can consider a binary coercion equivalent to an exact type match. When the opcintype is polymorphic, require that the old and new foreign types match exactly. (Since ri_triggers.c does use the executor, the stronger check for polymorphic types is no mere future-proofing. However, no core type exercises its necessity.) Author: Noah Misch Committer's note: catalog version bumped due to change of the Constraint node. I can't actually find any way to have such a node in a stored rule, but given that we have "out" support for them, better be safe.
2012-02-27 22:28:00 +01:00
tup = SearchSysCache1(CONSTROID, ObjectIdGetDatum(oldId));
if (!HeapTupleIsValid(tup)) /* should not happen */
elog(ERROR, "cache lookup failed for constraint %u", oldId);
adatum = SysCacheGetAttr(CONSTROID, tup,
Anum_pg_constraint_conpfeqop, &isNull);
if (isNull)
elog(ERROR, "null conpfeqop for constraint %u", oldId);
arr = DatumGetArrayTypeP(adatum); /* ensure not toasted */
numkeys = ARR_DIMS(arr)[0];
/* test follows the one in ri_FetchConstraintInfo() */
if (ARR_NDIM(arr) != 1 ||
ARR_HASNULL(arr) ||
ARR_ELEMTYPE(arr) != OIDOID)
elog(ERROR, "conpfeqop is not a 1-D Oid array");
rawarr = (Oid *) ARR_DATA_PTR(arr);
/* stash a List of the operator Oids in our Constraint node */
for (i = 0; i < numkeys; i++)
con->old_conpfeqop = lcons_oid(rawarr[i], con->old_conpfeqop);
ReleaseSysCache(tup);
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
* ALTER TABLE OWNER
ALTER TABLE OWNER must change the ownership of the table's rowtype too. This was not especially critical before, but it is now that we track ownership dependencies --- the dependency for the rowtype *must* shift to the new owner. Spotted by Bernd Helmle. Also fix a problem introduced by recent change to allow non-superusers to do ALTER OWNER in some cases: if the table had a toast table, ALTER OWNER failed *even for superusers*, because the test being applied would conclude that the new would-be owner had no create rights on pg_toast. A side-effect of the fix is to disallow changing the ownership of indexes or toast tables separately from their parent table, which seems a good idea on the whole.
2005-08-04 03:09:29 +02:00
*
Fix all known problems with pg_dump's handling of serial sequences 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.
2006-08-21 02:57:26 +02:00
* recursing is true if we are recursing from a table to its indexes,
* sequences, or toast table. We don't allow the ownership of those things to
* be changed separately from the parent table. Also, we can skip permission
ALTER TABLE OWNER must change the ownership of the table's rowtype too. This was not especially critical before, but it is now that we track ownership dependencies --- the dependency for the rowtype *must* shift to the new owner. Spotted by Bernd Helmle. Also fix a problem introduced by recent change to allow non-superusers to do ALTER OWNER in some cases: if the table had a toast table, ALTER OWNER failed *even for superusers*, because the test being applied would conclude that the new would-be owner had no create rights on pg_toast. A side-effect of the fix is to disallow changing the ownership of indexes or toast tables separately from their parent table, which seems a good idea on the whole.
2005-08-04 03:09:29 +02:00
* checks (this is necessary not just an optimization, else we'd fail to
* handle toast tables properly).
Support arrays of composite types, including the rowtypes of regular tables 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
2007-05-11 19:57:14 +02:00
*
* recursing is also true if ALTER TYPE OWNER is calling us to fix up a
* free-standing composite type.
Attached is a patch for ALTER TRIGGER RENAME per the above thread. I left a stub for a future "ALTER RULE RENAME" but did not write that one yet. Bruce, if you want to add my name for for that I'll take it and do it later. Joe Conway
2002-04-24 04:48:55 +02:00
*/
Implement DROP OWNED and REASSIGN OWNED. These new commands facilitate the process of dropping roles by dropping objects owned by them and privileges granted to them, or giving the owned objects to someone else, through the use of the data stored in the new pg_shdepend catalog. Some refactoring of the GRANT/REVOKE code was needed, as well as ALTER OWNER code. Further cleanup of code duplication in the GRANT code seems necessary. Implemented by me after an idea from Tom Lane, who also provided various kind of implementation advice. Regression tests pass. Some tests for the new functionality are also added, as well as rudimentary documentation.
2005-11-21 13:49:33 +01:00
void
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecChangeOwner(Oid relationOid, Oid newOwnerId, bool recursing, LOCKMODE lockmode)
Attached is a patch for ALTER TRIGGER RENAME per the above thread. I left a stub for a future "ALTER RULE RENAME" but did not write that one yet. Bruce, if you want to add my name for for that I'll take it and do it later. Joe Conway
2002-04-24 04:48:55 +02:00
{
pgindent run.
2002-09-04 22:31:48 +02:00
Relation target_rel;
Relation class_rel;
HeapTuple tuple;
Form_pg_class tuple_class;
Attached is a patch for ALTER TRIGGER RENAME per the above thread. I left a stub for a future "ALTER RULE RENAME" but did not write that one yet. Bruce, if you want to add my name for for that I'll take it and do it later. Joe Conway
2002-04-24 04:48:55 +02:00
Fix ALTER TABLE OWNER to adjust the ownership of dependent sequences, not only indexes. Alvaro Herrera, with some kibitzing by Tom Lane.
2004-09-24 01:20:24 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Get exclusive lock till end of transaction on the target table. Use
* relation_open so that we can work on indexes and sequences.
Fix ALTER TABLE OWNER to adjust the ownership of dependent sequences, not only indexes. Alvaro Herrera, with some kibitzing by Tom Lane.
2004-09-24 01:20:24 +02:00
*/
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
target_rel = relation_open(relationOid, lockmode);
Attached is a patch for ALTER TRIGGER RENAME per the above thread. I left a stub for a future "ALTER RULE RENAME" but did not write that one yet. Bruce, if you want to add my name for for that I'll take it and do it later. Joe Conway
2002-04-24 04:48:55 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/* Get its pg_class tuple, too */
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
class_rel = heap_open(RelationRelationId, RowExclusiveLock);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
Wrap calls to SearchSysCache and related functions using macros. The purpose of this change is to eliminate the need for every caller of SearchSysCache, SearchSysCacheCopy, SearchSysCacheExists, GetSysCacheOid, and SearchSysCacheList to know the maximum number of allowable keys for a syscache entry (currently 4). This will make it far easier to increase the maximum number of keys in a future release should we choose to do so, and it makes the code shorter, too. Design and review by Tom Lane.
2010-02-14 19:42:19 +01:00
tuple = SearchSysCache1(RELOID, ObjectIdGetDatum(relationOid));
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
if (!HeapTupleIsValid(tuple))
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
elog(ERROR, "cache lookup failed for relation %u", relationOid);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
tuple_class = (Form_pg_class) GETSTRUCT(tuple);
/* Can we change the ownership of this tuple? */
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
switch (tuple_class->relkind)
{
case RELKIND_RELATION:
case RELKIND_VIEW:
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
case RELKIND_MATVIEW:
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
case RELKIND_FOREIGN_TABLE:
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
/* ok to change owner */
break;
ALTER TABLE OWNER must change the ownership of the table's rowtype too. This was not especially critical before, but it is now that we track ownership dependencies --- the dependency for the rowtype *must* shift to the new owner. Spotted by Bernd Helmle. Also fix a problem introduced by recent change to allow non-superusers to do ALTER OWNER in some cases: if the table had a toast table, ALTER OWNER failed *even for superusers*, because the test being applied would conclude that the new would-be owner had no create rights on pg_toast. A side-effect of the fix is to disallow changing the ownership of indexes or toast tables separately from their parent table, which seems a good idea on the whole.
2005-08-04 03:09:29 +02:00
case RELKIND_INDEX:
Cause ALTER INDEX OWNER to generate a warning and do nothing, rather than erroring out as it has done for the last couple weeks. Document that this form is now ignored because indexes can't usefully have different owners from their parent tables. Fix pg_dump to not generate ALTER OWNER commands for indexes.
2005-08-22 21:40:37 +02:00
if (!recursing)
{
/*
* Because ALTER INDEX OWNER used to be allowed, and in fact
* is generated by old versions of pg_dump, we give a warning
* and do nothing rather than erroring out. Also, to avoid
* unnecessary chatter while restoring those old dumps, say
* nothing at all if the command would be a no-op anyway.
*/
if (tuple_class->relowner != newOwnerId)
ereport(WARNING,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("cannot change owner of index \"%s\"",
NameStr(tuple_class->relname)),
errhint("Change the ownership of the index's table, instead.")));
/* quick hack to exit via the no-op path */
newOwnerId = tuple_class->relowner;
}
break;
Fix all known problems with pg_dump's handling of serial sequences 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.
2006-08-21 02:57:26 +02:00
case RELKIND_SEQUENCE:
if (!recursing &&
tuple_class->relowner != newOwnerId)
{
/* if it's an owned sequence, disallow changing it by itself */
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
Oid tableId;
int32 colId;
Fix all known problems with pg_dump's handling of serial sequences 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.
2006-08-21 02:57:26 +02:00
if (sequenceIsOwned(relationOid, &tableId, &colId))
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot change owner of sequence \"%s\"",
NameStr(tuple_class->relname)),
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
errdetail("Sequence \"%s\" is linked to table \"%s\".",
NameStr(tuple_class->relname),
get_rel_name(tableId))));
Fix all known problems with pg_dump's handling of serial sequences 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.
2006-08-21 02:57:26 +02:00
}
break;
Support arrays of composite types, including the rowtypes of regular tables 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
2007-05-11 19:57:14 +02:00
case RELKIND_COMPOSITE_TYPE:
Improve consistency of the error messages generated when you try to use ALTER TABLE on a composite type or ALTER TYPE on a table's rowtype. We already rejected these cases, but the error messages were a bit random and didn't always provide a HINT to use the other command type.
2007-09-29 19:18:58 +02:00
if (recursing)
break;
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("\"%s\" is a composite type",
NameStr(tuple_class->relname)),
errhint("Use ALTER TYPE instead.")));
break;
case RELKIND_TOASTVALUE:
ALTER TABLE OWNER must change the ownership of the table's rowtype too. This was not especially critical before, but it is now that we track ownership dependencies --- the dependency for the rowtype *must* shift to the new owner. Spotted by Bernd Helmle. Also fix a problem introduced by recent change to allow non-superusers to do ALTER OWNER in some cases: if the table had a toast table, ALTER OWNER failed *even for superusers*, because the test being applied would conclude that the new would-be owner had no create rights on pg_toast. A side-effect of the fix is to disallow changing the ownership of indexes or toast tables separately from their parent table, which seems a good idea on the whole.
2005-08-04 03:09:29 +02:00
if (recursing)
break;
/* FALL THRU */
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
default:
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
Pgindent run before 9.1 beta2.
2011-06-09 20:32:50 +02:00
errmsg("\"%s\" is not a table, view, sequence, or foreign table",
NameStr(tuple_class->relname))));
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
}
Attached is a patch for ALTER TRIGGER RENAME per the above thread. I left a stub for a future "ALTER RULE RENAME" but did not write that one yet. Bruce, if you want to add my name for for that I'll take it and do it later. Joe Conway
2002-04-24 04:48:55 +02:00
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
/*
Support renaming of tablespaces, and changing the owners of aggregates, conversions, functions, operators, operator classes, schemas, types, and tablespaces. Fold the existing implementations of alter domain owner and alter database owner in with these. Christopher Kings-Lynne
2004-06-25 23:55:59 +02:00
* If the new owner is the same as the existing owner, consider the
* command to have succeeded. This is for dump restoration purposes.
Attached is a patch for ALTER TRIGGER RENAME per the above thread. I left a stub for a future "ALTER RULE RENAME" but did not write that one yet. Bruce, if you want to add my name for for that I'll take it and do it later. Joe Conway
2002-04-24 04:48:55 +02:00
*/
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
if (tuple_class->relowner != newOwnerId)
Support renaming of tablespaces, and changing the owners of aggregates, conversions, functions, operators, operator classes, schemas, types, and tablespaces. Fold the existing implementations of alter domain owner and alter database owner in with these. Christopher Kings-Lynne
2004-06-25 23:55:59 +02:00
{
Cause ALTER OWNER commands to update the object's ACL, replacing references to the old owner with the new owner. This is not necessarily right, but it's sure a lot more likely to be what the user wants than doing nothing. Christopher Kings-Lynne, some rework by Tom Lane.
2004-08-01 22:30:49 +02:00
Datum repl_val[Natts_pg_class];
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
bool repl_null[Natts_pg_class];
bool repl_repl[Natts_pg_class];
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
Acl *newAcl;
Cause ALTER OWNER commands to update the object's ACL, replacing references to the old owner with the new owner. This is not necessarily right, but it's sure a lot more likely to be what the user wants than doing nothing. Christopher Kings-Lynne, some rework by Tom Lane.
2004-08-01 22:30:49 +02:00
Datum aclDatum;
bool isNull;
HeapTuple newtuple;
Adjust permissions checking for ALTER OWNER commands: instead of requiring superuserness always, allow an owner to reassign ownership to any role he is a member of, if that role would have the right to create a similar object. These three requirements essentially state that the would-be alterer has enough privilege to DROP the existing object and then re-CREATE it as the new role; so we might as well let him do it in one step. The ALTER TABLESPACE case is a bit squirrely, but the whole concept of non-superuser tablespace owners is pretty dubious anyway. Stephen Frost, code review by Tom Lane.
2005-07-14 23:46:30 +02:00
ALTER TABLE OWNER must change the ownership of the table's rowtype too. This was not especially critical before, but it is now that we track ownership dependencies --- the dependency for the rowtype *must* shift to the new owner. Spotted by Bernd Helmle. Also fix a problem introduced by recent change to allow non-superusers to do ALTER OWNER in some cases: if the table had a toast table, ALTER OWNER failed *even for superusers*, because the test being applied would conclude that the new would-be owner had no create rights on pg_toast. A side-effect of the fix is to disallow changing the ownership of indexes or toast tables separately from their parent table, which seems a good idea on the whole.
2005-08-04 03:09:29 +02:00
/* skip permission checks when recursing to index or toast table */
if (!recursing)
{
Fix unwanted denial of ALTER OWNER rights to superusers. There was some discussion of getting around this by relaxing the checks made for regular users, but I'm disinclined to toy with the security model right now, so just special-case it for superusers where needed.
2005-08-22 19:38:20 +02:00
/* Superusers can always do it */
if (!superuser())
{
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
Oid namespaceOid = tuple_class->relnamespace;
Fix unwanted denial of ALTER OWNER rights to superusers. There was some discussion of getting around this by relaxing the checks made for regular users, but I'm disinclined to toy with the security model right now, so just special-case it for superusers where needed.
2005-08-22 19:38:20 +02:00
AclResult aclresult;
/* Otherwise, must be owner of the existing object */
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
if (!pg_class_ownercheck(relationOid, GetUserId()))
Fix unwanted denial of ALTER OWNER rights to superusers. There was some discussion of getting around this by relaxing the checks made for regular users, but I'm disinclined to toy with the security model right now, so just special-case it for superusers where needed.
2005-08-22 19:38:20 +02:00
aclcheck_error(ACLCHECK_NOT_OWNER, ACL_KIND_CLASS,
RelationGetRelationName(target_rel));
/* Must be able to become new owner */
check_is_member_of_role(GetUserId(), newOwnerId);
/* New owner must have CREATE privilege on namespace */
aclresult = pg_namespace_aclcheck(namespaceOid, newOwnerId,
ACL_CREATE);
if (aclresult != ACLCHECK_OK)
aclcheck_error(aclresult, ACL_KIND_NAMESPACE,
get_namespace_name(namespaceOid));
}
ALTER TABLE OWNER must change the ownership of the table's rowtype too. This was not especially critical before, but it is now that we track ownership dependencies --- the dependency for the rowtype *must* shift to the new owner. Spotted by Bernd Helmle. Also fix a problem introduced by recent change to allow non-superusers to do ALTER OWNER in some cases: if the table had a toast table, ALTER OWNER failed *even for superusers*, because the test being applied would conclude that the new would-be owner had no create rights on pg_toast. A side-effect of the fix is to disallow changing the ownership of indexes or toast tables separately from their parent table, which seems a good idea on the whole.
2005-08-04 03:09:29 +02:00
}
Attached is a patch for ALTER TRIGGER RENAME per the above thread. I left a stub for a future "ALTER RULE RENAME" but did not write that one yet. Bruce, if you want to add my name for for that I'll take it and do it later. Joe Conway
2002-04-24 04:48:55 +02:00
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
memset(repl_null, false, sizeof(repl_null));
memset(repl_repl, false, sizeof(repl_repl));
Cause ALTER OWNER commands to update the object's ACL, replacing references to the old owner with the new owner. This is not necessarily right, but it's sure a lot more likely to be what the user wants than doing nothing. Christopher Kings-Lynne, some rework by Tom Lane.
2004-08-01 22:30:49 +02:00
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
repl_repl[Anum_pg_class_relowner - 1] = true;
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
repl_val[Anum_pg_class_relowner - 1] = ObjectIdGetDatum(newOwnerId);
Cause ALTER OWNER commands to update the object's ACL, replacing references to the old owner with the new owner. This is not necessarily right, but it's sure a lot more likely to be what the user wants than doing nothing. Christopher Kings-Lynne, some rework by Tom Lane.
2004-08-01 22:30:49 +02:00
Support renaming of tablespaces, and changing the owners of aggregates, conversions, functions, operators, operator classes, schemas, types, and tablespaces. Fold the existing implementations of alter domain owner and alter database owner in with these. Christopher Kings-Lynne
2004-06-25 23:55:59 +02:00
/*
Cause ALTER OWNER commands to update the object's ACL, replacing references to the old owner with the new owner. This is not necessarily right, but it's sure a lot more likely to be what the user wants than doing nothing. Christopher Kings-Lynne, some rework by Tom Lane.
2004-08-01 22:30:49 +02:00
* Determine the modified ACL for the new owner. This is only
* necessary when the ACL is non-null.
Support renaming of tablespaces, and changing the owners of aggregates, conversions, functions, operators, operator classes, schemas, types, and tablespaces. Fold the existing implementations of alter domain owner and alter database owner in with these. Christopher Kings-Lynne
2004-06-25 23:55:59 +02:00
*/
Cause ALTER OWNER commands to update the object's ACL, replacing references to the old owner with the new owner. This is not necessarily right, but it's sure a lot more likely to be what the user wants than doing nothing. Christopher Kings-Lynne, some rework by Tom Lane.
2004-08-01 22:30:49 +02:00
aclDatum = SysCacheGetAttr(RELOID, tuple,
Anum_pg_class_relacl,
&isNull);
if (!isNull)
{
newAcl = aclnewowner(DatumGetAclP(aclDatum),
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
tuple_class->relowner, newOwnerId);
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
repl_repl[Anum_pg_class_relacl - 1] = true;
Cause ALTER OWNER commands to update the object's ACL, replacing references to the old owner with the new owner. This is not necessarily right, but it's sure a lot more likely to be what the user wants than doing nothing. Christopher Kings-Lynne, some rework by Tom Lane.
2004-08-01 22:30:49 +02:00
repl_val[Anum_pg_class_relacl - 1] = PointerGetDatum(newAcl);
}
Attached is a patch for ALTER TRIGGER RENAME per the above thread. I left a stub for a future "ALTER RULE RENAME" but did not write that one yet. Bruce, if you want to add my name for for that I'll take it and do it later. Joe Conway
2002-04-24 04:48:55 +02:00
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
newtuple = heap_modify_tuple(tuple, RelationGetDescr(class_rel), repl_val, repl_null, repl_repl);
Cause ALTER OWNER commands to update the object's ACL, replacing references to the old owner with the new owner. This is not necessarily right, but it's sure a lot more likely to be what the user wants than doing nothing. Christopher Kings-Lynne, some rework by Tom Lane.
2004-08-01 22:30:49 +02:00
simple_heap_update(class_rel, &newtuple->t_self, newtuple);
CatalogUpdateIndexes(class_rel, newtuple);
heap_freetuple(newtuple);
Attached is a patch for ALTER TRIGGER RENAME per the above thread. I left a stub for a future "ALTER RULE RENAME" but did not write that one yet. Bruce, if you want to add my name for for that I'll take it and do it later. Joe Conway
2002-04-24 04:48:55 +02:00
Update per-column ACLs, not only per-table ACL, when changing table owner. We forgot to modify column ACLs, so privileges were still shown as having been granted by the old owner. This meant that neither the new owner nor a superuser could revoke the now-untraceable-to-table-owner permissions. Per bug #6350 from Marc Balmer. This has been wrong since column ACLs were added, so back-patch to 8.4.
2011-12-22 00:23:11 +01:00
/*
* We must similarly update any per-column ACLs to reflect the new
* owner; for neatness reasons that's split out as a subroutine.
*/
change_owner_fix_column_acls(relationOid,
tuple_class->relowner,
newOwnerId);
Support arrays of composite types, including the rowtypes of regular tables 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
2007-05-11 19:57:14 +02:00
/*
* Update owner dependency reference, if any. A composite type has
* none, because it's tracked for the pg_type entry instead of here;
Get rid of the pg_shdepend entry for a TOAST table; it's unnecessary since 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.
2007-05-14 22:24:41 +02:00
* indexes and TOAST tables don't have their own entries either.
Support arrays of composite types, including the rowtypes of regular tables 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
2007-05-11 19:57:14 +02:00
*/
if (tuple_class->relkind != RELKIND_COMPOSITE_TYPE &&
Get rid of the pg_shdepend entry for a TOAST table; it's unnecessary since 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.
2007-05-14 22:24:41 +02:00
tuple_class->relkind != RELKIND_INDEX &&
tuple_class->relkind != RELKIND_TOASTVALUE)
Support arrays of composite types, including the rowtypes of regular tables 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
2007-05-11 19:57:14 +02:00
changeDependencyOnOwner(RelationRelationId, relationOid,
newOwnerId);
Track dependencies on shared objects (which is to say, roles; we already have adequate mechanisms for tracking the contents of databases and tablespaces). This solves the longstanding problem that you can drop a user who still owns objects and/or has access permissions. Alvaro Herrera, with some kibitzing from Tom Lane.
2005-07-07 22:40:02 +02:00
ALTER TABLE OWNER must change the ownership of the table's rowtype too. This was not especially critical before, but it is now that we track ownership dependencies --- the dependency for the rowtype *must* shift to the new owner. Spotted by Bernd Helmle. Also fix a problem introduced by recent change to allow non-superusers to do ALTER OWNER in some cases: if the table had a toast table, ALTER OWNER failed *even for superusers*, because the test being applied would conclude that the new would-be owner had no create rights on pg_toast. A side-effect of the fix is to disallow changing the ownership of indexes or toast tables separately from their parent table, which seems a good idea on the whole.
2005-08-04 03:09:29 +02:00
/*
Message style and spelling improvements
2011-06-21 23:33:20 +02:00
* Also change the ownership of the table's row type, if it has one
ALTER TABLE OWNER must change the ownership of the table's rowtype too. This was not especially critical before, but it is now that we track ownership dependencies --- the dependency for the rowtype *must* shift to the new owner. Spotted by Bernd Helmle. Also fix a problem introduced by recent change to allow non-superusers to do ALTER OWNER in some cases: if the table had a toast table, ALTER OWNER failed *even for superusers*, because the test being applied would conclude that the new would-be owner had no create rights on pg_toast. A side-effect of the fix is to disallow changing the ownership of indexes or toast tables separately from their parent table, which seems a good idea on the whole.
2005-08-04 03:09:29 +02:00
*/
if (tuple_class->relkind != RELKIND_INDEX)
Support arrays of composite types, including the rowtypes of regular tables 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
2007-05-11 19:57:14 +02:00
AlterTypeOwnerInternal(tuple_class->reltype, newOwnerId,
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
tuple_class->relkind == RELKIND_COMPOSITE_TYPE);
ALTER TABLE OWNER must change the ownership of the table's rowtype too. This was not especially critical before, but it is now that we track ownership dependencies --- the dependency for the rowtype *must* shift to the new owner. Spotted by Bernd Helmle. Also fix a problem introduced by recent change to allow non-superusers to do ALTER OWNER in some cases: if the table had a toast table, ALTER OWNER failed *even for superusers*, because the test being applied would conclude that the new would-be owner had no create rights on pg_toast. A side-effect of the fix is to disallow changing the ownership of indexes or toast tables separately from their parent table, which seems a good idea on the whole.
2005-08-04 03:09:29 +02:00
Support renaming of tablespaces, and changing the owners of aggregates, conversions, functions, operators, operator classes, schemas, types, and tablespaces. Fold the existing implementations of alter domain owner and alter database owner in with these. Christopher Kings-Lynne
2004-06-25 23:55:59 +02:00
/*
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
* If we are operating on a table or materialized view, also change
* the ownership of any indexes and sequences that belong to the
* relation, as well as its toast table (if it has one).
Support renaming of tablespaces, and changing the owners of aggregates, conversions, functions, operators, operator classes, schemas, types, and tablespaces. Fold the existing implementations of alter domain owner and alter database owner in with these. Christopher Kings-Lynne
2004-06-25 23:55:59 +02:00
*/
if (tuple_class->relkind == RELKIND_RELATION ||
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
tuple_class->relkind == RELKIND_MATVIEW ||
Support renaming of tablespaces, and changing the owners of aggregates, conversions, functions, operators, operator classes, schemas, types, and tablespaces. Fold the existing implementations of alter domain owner and alter database owner in with these. Christopher Kings-Lynne
2004-06-25 23:55:59 +02:00
tuple_class->relkind == RELKIND_TOASTVALUE)
{
List *index_oid_list;
ListCell *i;
Attached is a patch for ALTER TRIGGER RENAME per the above thread. I left a stub for a future "ALTER RULE RENAME" but did not write that one yet. Bruce, if you want to add my name for for that I'll take it and do it later. Joe Conway
2002-04-24 04:48:55 +02:00
Support renaming of tablespaces, and changing the owners of aggregates, conversions, functions, operators, operator classes, schemas, types, and tablespaces. Fold the existing implementations of alter domain owner and alter database owner in with these. Christopher Kings-Lynne
2004-06-25 23:55:59 +02:00
/* Find all the indexes belonging to this relation */
index_oid_list = RelationGetIndexList(target_rel);
Attached is a patch for ALTER TRIGGER RENAME per the above thread. I left a stub for a future "ALTER RULE RENAME" but did not write that one yet. Bruce, if you want to add my name for for that I'll take it and do it later. Joe Conway
2002-04-24 04:48:55 +02:00
Support renaming of tablespaces, and changing the owners of aggregates, conversions, functions, operators, operator classes, schemas, types, and tablespaces. Fold the existing implementations of alter domain owner and alter database owner in with these. Christopher Kings-Lynne
2004-06-25 23:55:59 +02:00
/* For each index, recursively change its ownership */
foreach(i, index_oid_list)
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecChangeOwner(lfirst_oid(i), newOwnerId, true, lockmode);
Attached is a patch for ALTER TRIGGER RENAME per the above thread. I left a stub for a future "ALTER RULE RENAME" but did not write that one yet. Bruce, if you want to add my name for for that I'll take it and do it later. Joe Conway
2002-04-24 04:48:55 +02:00
Support renaming of tablespaces, and changing the owners of aggregates, conversions, functions, operators, operator classes, schemas, types, and tablespaces. Fold the existing implementations of alter domain owner and alter database owner in with these. Christopher Kings-Lynne
2004-06-25 23:55:59 +02:00
list_free(index_oid_list);
}
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
if (tuple_class->relkind == RELKIND_RELATION ||
tuple_class->relkind == RELKIND_MATVIEW)
Support renaming of tablespaces, and changing the owners of aggregates, conversions, functions, operators, operator classes, schemas, types, and tablespaces. Fold the existing implementations of alter domain owner and alter database owner in with these. Christopher Kings-Lynne
2004-06-25 23:55:59 +02:00
{
/* If it has a toast table, recurse to change its ownership */
if (tuple_class->reltoastrelid != InvalidOid)
ALTER TABLE OWNER must change the ownership of the table's rowtype too. This was not especially critical before, but it is now that we track ownership dependencies --- the dependency for the rowtype *must* shift to the new owner. Spotted by Bernd Helmle. Also fix a problem introduced by recent change to allow non-superusers to do ALTER OWNER in some cases: if the table had a toast table, ALTER OWNER failed *even for superusers*, because the test being applied would conclude that the new would-be owner had no create rights on pg_toast. A side-effect of the fix is to disallow changing the ownership of indexes or toast tables separately from their parent table, which seems a good idea on the whole.
2005-08-04 03:09:29 +02:00
ATExecChangeOwner(tuple_class->reltoastrelid, newOwnerId,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
true, lockmode);
Fix ALTER TABLE OWNER to adjust the ownership of dependent sequences, not only indexes. Alvaro Herrera, with some kibitzing by Tom Lane.
2004-09-24 01:20:24 +02:00
/* If it has dependent sequences, recurse to change them too */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
change_owner_recurse_to_sequences(relationOid, newOwnerId, lockmode);
Support renaming of tablespaces, and changing the owners of aggregates, conversions, functions, operators, operator classes, schemas, types, and tablespaces. Fold the existing implementations of alter domain owner and alter database owner in with these. Christopher Kings-Lynne
2004-06-25 23:55:59 +02:00
}
Attached is a patch for ALTER TRIGGER RENAME per the above thread. I left a stub for a future "ALTER RULE RENAME" but did not write that one yet. Bruce, if you want to add my name for for that I'll take it and do it later. Joe Conway
2002-04-24 04:48:55 +02:00
}
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
InvokeObjectPostAlterHook(RelationRelationId, relationOid, 0);
Cause ALTER OWNER commands to update the object's ACL, replacing references to the old owner with the new owner. This is not necessarily right, but it's sure a lot more likely to be what the user wants than doing nothing. Christopher Kings-Lynne, some rework by Tom Lane.
2004-08-01 22:30:49 +02:00
ReleaseSysCache(tuple);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
heap_close(class_rel, RowExclusiveLock);
Repair AlterTableOwner --- was failing for relations with indexes.
2002-06-17 16:31:32 +02:00
relation_close(target_rel, NoLock);
Attached is a patch for ALTER TRIGGER RENAME per the above thread. I left a stub for a future "ALTER RULE RENAME" but did not write that one yet. Bruce, if you want to add my name for for that I'll take it and do it later. Joe Conway
2002-04-24 04:48:55 +02:00
}
Update per-column ACLs, not only per-table ACL, when changing table owner. We forgot to modify column ACLs, so privileges were still shown as having been granted by the old owner. This meant that neither the new owner nor a superuser could revoke the now-untraceable-to-table-owner permissions. Per bug #6350 from Marc Balmer. This has been wrong since column ACLs were added, so back-patch to 8.4.
2011-12-22 00:23:11 +01:00
/*
* change_owner_fix_column_acls
*
* Helper function for ATExecChangeOwner. Scan the columns of the table
* and fix any non-null column ACLs to reflect the new owner.
*/
static void
change_owner_fix_column_acls(Oid relationOid, Oid oldOwnerId, Oid newOwnerId)
{
Relation attRelation;
SysScanDesc scan;
ScanKeyData key[1];
HeapTuple attributeTuple;
attRelation = heap_open(AttributeRelationId, RowExclusiveLock);
ScanKeyInit(&key[0],
Anum_pg_attribute_attrelid,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(relationOid));
scan = systable_beginscan(attRelation, AttributeRelidNumIndexId,
true, SnapshotNow, 1, key);
while (HeapTupleIsValid(attributeTuple = systable_getnext(scan)))
{
Form_pg_attribute att = (Form_pg_attribute) GETSTRUCT(attributeTuple);
Datum repl_val[Natts_pg_attribute];
bool repl_null[Natts_pg_attribute];
bool repl_repl[Natts_pg_attribute];
Acl *newAcl;
Datum aclDatum;
bool isNull;
HeapTuple newtuple;
/* Ignore dropped columns */
if (att->attisdropped)
continue;
aclDatum = heap_getattr(attributeTuple,
Anum_pg_attribute_attacl,
RelationGetDescr(attRelation),
&isNull);
/* Null ACLs do not require changes */
if (isNull)
continue;
memset(repl_null, false, sizeof(repl_null));
memset(repl_repl, false, sizeof(repl_repl));
newAcl = aclnewowner(DatumGetAclP(aclDatum),
oldOwnerId, newOwnerId);
repl_repl[Anum_pg_attribute_attacl - 1] = true;
repl_val[Anum_pg_attribute_attacl - 1] = PointerGetDatum(newAcl);
newtuple = heap_modify_tuple(attributeTuple,
RelationGetDescr(attRelation),
repl_val, repl_null, repl_repl);
simple_heap_update(attRelation, &newtuple->t_self, newtuple);
CatalogUpdateIndexes(attRelation, newtuple);
heap_freetuple(newtuple);
}
systable_endscan(scan);
heap_close(attRelation, RowExclusiveLock);
}
Fix ALTER TABLE OWNER to adjust the ownership of dependent sequences, not only indexes. Alvaro Herrera, with some kibitzing by Tom Lane.
2004-09-24 01:20:24 +02:00
/*
* change_owner_recurse_to_sequences
*
* Helper function for ATExecChangeOwner. Examines pg_depend searching
* for sequences that are dependent on serial columns, and changes their
* ownership.
*/
static void
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
change_owner_recurse_to_sequences(Oid relationOid, Oid newOwnerId, LOCKMODE lockmode)
Fix ALTER TABLE OWNER to adjust the ownership of dependent sequences, not only indexes. Alvaro Herrera, with some kibitzing by Tom Lane.
2004-09-24 01:20:24 +02:00
{
Relation depRel;
SysScanDesc scan;
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
ScanKeyData key[2];
Fix ALTER TABLE OWNER to adjust the ownership of dependent sequences, not only indexes. Alvaro Herrera, with some kibitzing by Tom Lane.
2004-09-24 01:20:24 +02:00
HeapTuple tup;
/*
Fix all known problems with pg_dump's handling of serial sequences 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.
2006-08-21 02:57:26 +02:00
* SERIAL sequences are those having an auto dependency on one of the
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* table's columns (we don't care *which* column, exactly).
Fix ALTER TABLE OWNER to adjust the ownership of dependent sequences, not only indexes. Alvaro Herrera, with some kibitzing by Tom Lane.
2004-09-24 01:20:24 +02:00
*/
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
depRel = heap_open(DependRelationId, AccessShareLock);
Fix ALTER TABLE OWNER to adjust the ownership of dependent sequences, not only indexes. Alvaro Herrera, with some kibitzing by Tom Lane.
2004-09-24 01:20:24 +02:00
ScanKeyInit(&key[0],
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
Anum_pg_depend_refclassid,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(RelationRelationId));
Fix ALTER TABLE OWNER to adjust the ownership of dependent sequences, not only indexes. Alvaro Herrera, with some kibitzing by Tom Lane.
2004-09-24 01:20:24 +02:00
ScanKeyInit(&key[1],
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
Anum_pg_depend_refobjid,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(relationOid));
Fix ALTER TABLE OWNER to adjust the ownership of dependent sequences, not only indexes. Alvaro Herrera, with some kibitzing by Tom Lane.
2004-09-24 01:20:24 +02:00
/* we leave refobjsubid unspecified */
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
scan = systable_beginscan(depRel, DependReferenceIndexId, true,
Fix ALTER TABLE OWNER to adjust the ownership of dependent sequences, not only indexes. Alvaro Herrera, with some kibitzing by Tom Lane.
2004-09-24 01:20:24 +02:00
SnapshotNow, 2, key);
while (HeapTupleIsValid(tup = systable_getnext(scan)))
{
Form_pg_depend depForm = (Form_pg_depend) GETSTRUCT(tup);
Relation seqRel;
Fix all known problems with pg_dump's handling of serial sequences 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.
2006-08-21 02:57:26 +02:00
/* skip dependencies other than auto dependencies on columns */
Fix ALTER TABLE OWNER to adjust the ownership of dependent sequences, not only indexes. Alvaro Herrera, with some kibitzing by Tom Lane.
2004-09-24 01:20:24 +02:00
if (depForm->refobjsubid == 0 ||
First phase of project to use fixed OIDs for all system catalogs and indexes. Extend the macros in include/catalog/*.h to carry the info about hand-assigned OIDs, and adjust the genbki script and bootstrap code to make the relations actually get those OIDs. Remove the small number of RelOid_pg_foo macros that we had in favor of a complete set named like the catname.h and indexing.h macros. Next phase will get rid of internal use of names for looking up catalogs and indexes; but this completes the changes forcing an initdb, so it looks like a good place to commit. Along the way, I made the shared relations (pg_database etc) not be 'bootstrap' relations any more, so as to reduce the number of hardwired entries and simplify changing those relations in future. I'm not sure whether they ever really needed to be handled as bootstrap relations, but it seems to work fine to not do so now.
2005-04-14 03:38:22 +02:00
depForm->classid != RelationRelationId ||
Fix ALTER TABLE OWNER to adjust the ownership of dependent sequences, not only indexes. Alvaro Herrera, with some kibitzing by Tom Lane.
2004-09-24 01:20:24 +02:00
depForm->objsubid != 0 ||
Fix all known problems with pg_dump's handling of serial sequences 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.
2006-08-21 02:57:26 +02:00
depForm->deptype != DEPENDENCY_AUTO)
Fix ALTER TABLE OWNER to adjust the ownership of dependent sequences, not only indexes. Alvaro Herrera, with some kibitzing by Tom Lane.
2004-09-24 01:20:24 +02:00
continue;
/* Use relation_open just in case it's an index */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
seqRel = relation_open(depForm->objid, lockmode);
Fix ALTER TABLE OWNER to adjust the ownership of dependent sequences, not only indexes. Alvaro Herrera, with some kibitzing by Tom Lane.
2004-09-24 01:20:24 +02:00
/* skip non-sequence relations */
if (RelationGetForm(seqRel)->relkind != RELKIND_SEQUENCE)
{
/* No need to keep the lock */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
relation_close(seqRel, lockmode);
Fix ALTER TABLE OWNER to adjust the ownership of dependent sequences, not only indexes. Alvaro Herrera, with some kibitzing by Tom Lane.
2004-09-24 01:20:24 +02:00
continue;
}
/* We don't need to close the sequence while we alter it. */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecChangeOwner(depForm->objid, newOwnerId, true, lockmode);
Fix ALTER TABLE OWNER to adjust the ownership of dependent sequences, not only indexes. Alvaro Herrera, with some kibitzing by Tom Lane.
2004-09-24 01:20:24 +02:00
/* Now we can close it. Keep the lock till end of transaction. */
relation_close(seqRel, NoLock);
}
systable_endscan(scan);
Fix two bugs in change_owner_recurse_to_sequences: it was grabbing an overly strong lock on pg_depend, and it wasn't closing the rel when done. The latter bug was masked by the ResourceOwner code, which is something that should be changed.
2005-03-25 19:04:34 +01:00
relation_close(depRel, AccessShareLock);
Fix ALTER TABLE OWNER to adjust the ownership of dependent sequences, not only indexes. Alvaro Herrera, with some kibitzing by Tom Lane.
2004-09-24 01:20:24 +02:00
}
Add ALTER TABLE <tablename> CLUSTER ON <indexname> Alvaro Herrera
2003-03-20 19:52:48 +01:00
/*
* ALTER TABLE CLUSTER ON
*
* The only thing we have to do is to change the indisclustered bits.
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static void
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecClusterOn(Relation rel, const char *indexName, LOCKMODE lockmode)
Add ALTER TABLE <tablename> CLUSTER ON <indexname> Alvaro Herrera
2003-03-20 19:52:48 +01:00
{
pgindent run.
2003-08-04 02:43:34 +02:00
Oid indexOid;
Add ALTER TABLE <tablename> CLUSTER ON <indexname> Alvaro Herrera
2003-03-20 19:52:48 +01:00
indexOid = get_relname_relid(indexName, rel->rd_rel->relnamespace);
pgindent run.
2003-08-04 02:43:34 +02:00
Add ALTER TABLE <tablename> CLUSTER ON <indexname> Alvaro Herrera
2003-03-20 19:52:48 +01:00
if (!OidIsValid(indexOid))
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_OBJECT),
errmsg("index \"%s\" for table \"%s\" does not exist",
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
indexName, RelationGetRelationName(rel))));
Add ALTER TABLE <tablename> CLUSTER ON <indexname> Alvaro Herrera
2003-03-20 19:52:48 +01:00
Make ALTER COLUMN TYPE preserve clustered status for indexes it doesn't modify. Also fix a passel of problems with ALTER TABLE CLUSTER ON: failure to check that the index is safe to cluster on (or even belongs to the indicated rel, or even exists), and failure to broadcast a relcache flush event when changing an index's state.
2004-05-06 18:10:57 +02:00
/* Check index is valid to cluster on */
Add explicit regression tests for ALTER TABLE lock levels. Use this to catch a couple of lock level assignments that slipped through manual testing, per Peter Eisentraut.
2010-07-29 13:06:34 +02:00
check_index_is_clusterable(rel, indexOid, false, lockmode);
Make ALTER COLUMN TYPE preserve clustered status for indexes it doesn't modify. Also fix a passel of problems with ALTER TABLE CLUSTER ON: failure to check that the index is safe to cluster on (or even belongs to the indicated rel, or even exists), and failure to broadcast a relcache flush event when changing an index's state.
2004-05-06 18:10:57 +02:00
Get rid of cluster.c's apparatus for rebuilding a relation's indexes in favor of using the REINDEX TABLE apparatus, which does the same thing simpler and faster. Also, make TRUNCATE not use cluster.c at all, but just assign a new relfilenode and REINDEX. This partially addresses Hartmut Raschick's complaint from last December that 7.4's TRUNCATE is an order of magnitude slower than prior releases. By getting rid of a lot of unnecessary catalog updates, these changes buy back about a factor of two (on my system). The remaining overhead seems associated with creating and deleting storage files, which we may not be able to do much about without abandoning transaction safety for TRUNCATE.
2004-05-08 02:34:49 +02:00
/* And do the work */
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
mark_index_clustered(rel, indexOid, false);
Add ALTER TABLE <tablename> CLUSTER ON <indexname> Alvaro Herrera
2003-03-20 19:52:48 +01:00
}
OK, here's the final version of ALTER TABLE ... SET WITHOUT CLUSTER. Has docs + regression test. Christopher Kings-Lynne
2004-06-02 23:01:10 +02:00
/*
* ALTER TABLE SET WITHOUT CLUSTER
*
* We have to find any indexes on the table that have indisclustered bit
* set and turn it off.
*/
static void
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecDropCluster(Relation rel, LOCKMODE lockmode)
OK, here's the final version of ALTER TABLE ... SET WITHOUT CLUSTER. Has docs + regression test. Christopher Kings-Lynne
2004-06-02 23:01:10 +02:00
{
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
mark_index_clustered(rel, InvalidOid, false);
OK, here's the final version of ALTER TABLE ... SET WITHOUT CLUSTER. Has docs + regression test. Christopher Kings-Lynne
2004-06-02 23:01:10 +02:00
}
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
/*
* ALTER TABLE SET TABLESPACE
*/
static void
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATPrepSetTableSpace(AlteredTableInfo *tab, Relation rel, char *tablespacename, LOCKMODE lockmode)
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
{
Oid tablespaceId;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
AclResult aclresult;
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
/* Check that the tablespace exists */
Standardize get_whatever_oid functions for object types with unqualified names. - Add a missing_ok parameter to get_tablespace_oid. - Avoid duplicating get_tablespace_od guts in objectNamesToOids. - Add a missing_ok parameter to get_database_oid. - Replace get_roleid and get_role_checked with get_role_oid. - Add get_namespace_oid, get_language_oid, get_am_oid. - Refactor existing code to use new interfaces. Thanks to KaiGai Kohei for the review.
2010-08-05 16:45:09 +02:00
tablespaceId = get_tablespace_oid(tablespacename, false);
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
/* Check its permissions */
aclresult = pg_tablespace_aclcheck(tablespaceId, GetUserId(), ACL_CREATE);
if (aclresult != ACLCHECK_OK)
aclcheck_error(aclresult, ACL_KIND_TABLESPACE, tablespacename);
/* Save info for Phase 3 to do the real work */
if (OidIsValid(tab->newTableSpace))
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("cannot have multiple SET TABLESPACE subcommands")));
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
tab->newTableSpace = tablespaceId;
}
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
/*
Add a security_barrier option for views. When a view is marked as a security barrier, it will not be pulled up into the containing query, and no quals will be pushed down into it, so that no function or operator chosen by the user can be applied to rows not exposed by the view. Views not configured with this option cannot provide robust row-level security, but will perform far better. Patch by KaiGai Kohei; original problem report by Heikki Linnakangas (in October 2009!). Review (in earlier versions) by Noah Misch and others. Design advice by Tom Lane and myself. Further review and cleanup by me.
2011-12-22 22:15:57 +01:00
* Set, reset, or replace reloptions.
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
*/
static void
Add a security_barrier option for views. When a view is marked as a security barrier, it will not be pulled up into the containing query, and no quals will be pushed down into it, so that no function or operator chosen by the user can be applied to rows not exposed by the view. Views not configured with this option cannot provide robust row-level security, but will perform far better. Patch by KaiGai Kohei; original problem report by Heikki Linnakangas (in October 2009!). Review (in earlier versions) by Noah Misch and others. Design advice by Tom Lane and myself. Further review and cleanup by me.
2011-12-22 22:15:57 +01:00
ATExecSetRelOptions(Relation rel, List *defList, AlterTableType operation,
LOCKMODE lockmode)
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
{
Oid relid;
Relation pgclass;
HeapTuple tuple;
Code review for FILLFACTOR patch. Change WITH grammar as per earlier 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.
2006-07-04 00:45:41 +02:00
HeapTuple newtuple;
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
Datum datum;
bool isnull;
Code review for FILLFACTOR patch. Change WITH grammar as per earlier 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.
2006-07-04 00:45:41 +02:00
Datum newOptions;
Datum repl_val[Natts_pg_class];
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
bool repl_null[Natts_pg_class];
bool repl_repl[Natts_pg_class];
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
static char *validnsps[] = HEAP_RELOPT_NAMESPACES;
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
Add a security_barrier option for views. When a view is marked as a security barrier, it will not be pulled up into the containing query, and no quals will be pushed down into it, so that no function or operator chosen by the user can be applied to rows not exposed by the view. Views not configured with this option cannot provide robust row-level security, but will perform far better. Patch by KaiGai Kohei; original problem report by Heikki Linnakangas (in October 2009!). Review (in earlier versions) by Noah Misch and others. Design advice by Tom Lane and myself. Further review and cleanup by me.
2011-12-22 22:15:57 +01:00
if (defList == NIL && operation != AT_ReplaceRelOptions)
Code review for FILLFACTOR patch. Change WITH grammar as per earlier 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.
2006-07-04 00:45:41 +02:00
return; /* nothing to do */
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
pgclass = heap_open(RelationRelationId, RowExclusiveLock);
Code review for FILLFACTOR patch. Change WITH grammar as per earlier 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.
2006-07-04 00:45:41 +02:00
Add a security_barrier option for views. When a view is marked as a security barrier, it will not be pulled up into the containing query, and no quals will be pushed down into it, so that no function or operator chosen by the user can be applied to rows not exposed by the view. Views not configured with this option cannot provide robust row-level security, but will perform far better. Patch by KaiGai Kohei; original problem report by Heikki Linnakangas (in October 2009!). Review (in earlier versions) by Noah Misch and others. Design advice by Tom Lane and myself. Further review and cleanup by me.
2011-12-22 22:15:57 +01:00
/* Fetch heap tuple */
Code review for FILLFACTOR patch. Change WITH grammar as per earlier 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.
2006-07-04 00:45:41 +02:00
relid = RelationGetRelid(rel);
Wrap calls to SearchSysCache and related functions using macros. The purpose of this change is to eliminate the need for every caller of SearchSysCache, SearchSysCacheCopy, SearchSysCacheExists, GetSysCacheOid, and SearchSysCacheList to know the maximum number of allowable keys for a syscache entry (currently 4). This will make it far easier to increase the maximum number of keys in a future release should we choose to do so, and it makes the code shorter, too. Design and review by Tom Lane.
2010-02-14 19:42:19 +01:00
tuple = SearchSysCache1(RELOID, ObjectIdGetDatum(relid));
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
if (!HeapTupleIsValid(tuple))
elog(ERROR, "cache lookup failed for relation %u", relid);
Add a security_barrier option for views. When a view is marked as a security barrier, it will not be pulled up into the containing query, and no quals will be pushed down into it, so that no function or operator chosen by the user can be applied to rows not exposed by the view. Views not configured with this option cannot provide robust row-level security, but will perform far better. Patch by KaiGai Kohei; original problem report by Heikki Linnakangas (in October 2009!). Review (in earlier versions) by Noah Misch and others. Design advice by Tom Lane and myself. Further review and cleanup by me.
2011-12-22 22:15:57 +01:00
if (operation == AT_ReplaceRelOptions)
{
/*
* If we're supposed to replace the reloptions list, we just pretend
* there were none before.
*/
datum = (Datum) 0;
isnull = true;
}
else
{
/* Get the old reloptions */
datum = SysCacheGetAttr(RELOID, tuple, Anum_pg_class_reloptions,
&isnull);
}
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
Code review for FILLFACTOR patch. Change WITH grammar as per earlier 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.
2006-07-04 00:45:41 +02:00
/* Generate new proposed reloptions (text array) */
newOptions = transformRelOptions(isnull ? (Datum) 0 : datum,
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
defList, NULL, validnsps, false,
operation == AT_ResetRelOptions);
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
Code review for FILLFACTOR patch. Change WITH grammar as per earlier 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.
2006-07-04 00:45:41 +02:00
/* Validate */
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
switch (rel->rd_rel->relkind)
{
case RELKIND_RELATION:
case RELKIND_TOASTVALUE:
Add a security_barrier option for views. When a view is marked as a security barrier, it will not be pulled up into the containing query, and no quals will be pushed down into it, so that no function or operator chosen by the user can be applied to rows not exposed by the view. Views not configured with this option cannot provide robust row-level security, but will perform far better. Patch by KaiGai Kohei; original problem report by Heikki Linnakangas (in October 2009!). Review (in earlier versions) by Noah Misch and others. Design advice by Tom Lane and myself. Further review and cleanup by me.
2011-12-22 22:15:57 +01:00
case RELKIND_VIEW:
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
case RELKIND_MATVIEW:
Code review for FILLFACTOR patch. Change WITH grammar as per earlier 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.
2006-07-04 00:45:41 +02:00
(void) heap_reloptions(rel->rd_rel->relkind, newOptions, true);
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
break;
case RELKIND_INDEX:
Code review for FILLFACTOR patch. Change WITH grammar as per earlier 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.
2006-07-04 00:45:41 +02:00
(void) index_reloptions(rel->rd_am->amoptions, newOptions, true);
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
break;
default:
Code review for FILLFACTOR patch. Change WITH grammar as per earlier 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.
2006-07-04 00:45:41 +02:00
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
errmsg("\"%s\" is not a table, view, materialized view, index, or TOAST table",
Code review for FILLFACTOR patch. Change WITH grammar as per earlier 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.
2006-07-04 00:45:41 +02:00
RelationGetRelationName(rel))));
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
break;
}
Code review for FILLFACTOR patch. Change WITH grammar as per earlier 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.
2006-07-04 00:45:41 +02:00
/*
* All we need do here is update the pg_class row; the new options will be
* propagated into relcaches during post-commit cache inval.
*/
memset(repl_val, 0, sizeof(repl_val));
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
memset(repl_null, false, sizeof(repl_null));
memset(repl_repl, false, sizeof(repl_repl));
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
Code review for FILLFACTOR patch. Change WITH grammar as per earlier 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.
2006-07-04 00:45:41 +02:00
if (newOptions != (Datum) 0)
repl_val[Anum_pg_class_reloptions - 1] = newOptions;
else
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
repl_null[Anum_pg_class_reloptions - 1] = true;
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
repl_repl[Anum_pg_class_reloptions - 1] = true;
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
newtuple = heap_modify_tuple(tuple, RelationGetDescr(pgclass),
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
repl_val, repl_null, repl_repl);
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
Code review for FILLFACTOR patch. Change WITH grammar as per earlier 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.
2006-07-04 00:45:41 +02:00
simple_heap_update(pgclass, &newtuple->t_self, newtuple);
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
Code review for FILLFACTOR patch. Change WITH grammar as per earlier 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.
2006-07-04 00:45:41 +02:00
CatalogUpdateIndexes(pgclass, newtuple);
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
InvokeObjectPostAlterHook(RelationRelationId, RelationGetRelid(rel), 0);
Code review for FILLFACTOR patch. Change WITH grammar as per earlier 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.
2006-07-04 00:45:41 +02:00
heap_freetuple(newtuple);
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
ReleaseSysCache(tuple);
Code review for FILLFACTOR patch. Change WITH grammar as per earlier 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.
2006-07-04 00:45:41 +02:00
Allow reloption names to have qualifiers, initially supporting a TOAST qualifier, and add support for this in pg_dump. This allows TOAST tables to have user-defined fillfactor, and will also enable us to move the autovacuum parameters to reloptions without taking away the possibility of setting values for TOAST tables.
2009-02-02 20:31:40 +01:00
/* repeat the whole exercise for the toast table, if there's one */
if (OidIsValid(rel->rd_rel->reltoastrelid))
{
Relation toastrel;
Oid toastid = rel->rd_rel->reltoastrelid;
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
toastrel = heap_open(toastid, lockmode);
Allow reloption names to have qualifiers, initially supporting a TOAST qualifier, and add support for this in pg_dump. This allows TOAST tables to have user-defined fillfactor, and will also enable us to move the autovacuum parameters to reloptions without taking away the possibility of setting values for TOAST tables.
2009-02-02 20:31:40 +01:00
Add a security_barrier option for views. When a view is marked as a security barrier, it will not be pulled up into the containing query, and no quals will be pushed down into it, so that no function or operator chosen by the user can be applied to rows not exposed by the view. Views not configured with this option cannot provide robust row-level security, but will perform far better. Patch by KaiGai Kohei; original problem report by Heikki Linnakangas (in October 2009!). Review (in earlier versions) by Noah Misch and others. Design advice by Tom Lane and myself. Further review and cleanup by me.
2011-12-22 22:15:57 +01:00
/* Fetch heap tuple */
Wrap calls to SearchSysCache and related functions using macros. The purpose of this change is to eliminate the need for every caller of SearchSysCache, SearchSysCacheCopy, SearchSysCacheExists, GetSysCacheOid, and SearchSysCacheList to know the maximum number of allowable keys for a syscache entry (currently 4). This will make it far easier to increase the maximum number of keys in a future release should we choose to do so, and it makes the code shorter, too. Design and review by Tom Lane.
2010-02-14 19:42:19 +01:00
tuple = SearchSysCache1(RELOID, ObjectIdGetDatum(toastid));
Allow reloption names to have qualifiers, initially supporting a TOAST qualifier, and add support for this in pg_dump. This allows TOAST tables to have user-defined fillfactor, and will also enable us to move the autovacuum parameters to reloptions without taking away the possibility of setting values for TOAST tables.
2009-02-02 20:31:40 +01:00
if (!HeapTupleIsValid(tuple))
elog(ERROR, "cache lookup failed for relation %u", toastid);
Add a security_barrier option for views. When a view is marked as a security barrier, it will not be pulled up into the containing query, and no quals will be pushed down into it, so that no function or operator chosen by the user can be applied to rows not exposed by the view. Views not configured with this option cannot provide robust row-level security, but will perform far better. Patch by KaiGai Kohei; original problem report by Heikki Linnakangas (in October 2009!). Review (in earlier versions) by Noah Misch and others. Design advice by Tom Lane and myself. Further review and cleanup by me.
2011-12-22 22:15:57 +01:00
if (operation == AT_ReplaceRelOptions)
{
/*
* If we're supposed to replace the reloptions list, we just
* pretend there were none before.
*/
datum = (Datum) 0;
isnull = true;
}
else
{
/* Get the old reloptions */
datum = SysCacheGetAttr(RELOID, tuple, Anum_pg_class_reloptions,
&isnull);
}
Allow reloption names to have qualifiers, initially supporting a TOAST qualifier, and add support for this in pg_dump. This allows TOAST tables to have user-defined fillfactor, and will also enable us to move the autovacuum parameters to reloptions without taking away the possibility of setting values for TOAST tables.
2009-02-02 20:31:40 +01:00
newOptions = transformRelOptions(isnull ? (Datum) 0 : datum,
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
defList, "toast", validnsps, false,
operation == AT_ResetRelOptions);
Allow reloption names to have qualifiers, initially supporting a TOAST qualifier, and add support for this in pg_dump. This allows TOAST tables to have user-defined fillfactor, and will also enable us to move the autovacuum parameters to reloptions without taking away the possibility of setting values for TOAST tables.
2009-02-02 20:31:40 +01:00
(void) heap_reloptions(RELKIND_TOASTVALUE, newOptions, true);
memset(repl_val, 0, sizeof(repl_val));
memset(repl_null, false, sizeof(repl_null));
memset(repl_repl, false, sizeof(repl_repl));
if (newOptions != (Datum) 0)
repl_val[Anum_pg_class_reloptions - 1] = newOptions;
else
repl_null[Anum_pg_class_reloptions - 1] = true;
repl_repl[Anum_pg_class_reloptions - 1] = true;
newtuple = heap_modify_tuple(tuple, RelationGetDescr(pgclass),
repl_val, repl_null, repl_repl);
simple_heap_update(pgclass, &newtuple->t_self, newtuple);
CatalogUpdateIndexes(pgclass, newtuple);
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
InvokeObjectPostAlterHookArg(RelationRelationId,
RelationGetRelid(toastrel), 0,
InvalidOid, true);
Allow reloption names to have qualifiers, initially supporting a TOAST qualifier, and add support for this in pg_dump. This allows TOAST tables to have user-defined fillfactor, and will also enable us to move the autovacuum parameters to reloptions without taking away the possibility of setting values for TOAST tables.
2009-02-02 20:31:40 +01:00
heap_freetuple(newtuple);
ReleaseSysCache(tuple);
heap_close(toastrel, NoLock);
}
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
heap_close(pgclass, RowExclusiveLock);
}
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
/*
* Execute ALTER TABLE SET TABLESPACE for cases where there is no tuple
* rewriting to be done, so we just want to copy the data as fast as possible.
*/
static void
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecSetTableSpace(Oid tableOid, Oid newTableSpace, LOCKMODE lockmode)
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
{
Relation rel;
Oid oldTableSpace;
Oid reltoastrelid;
Oid reltoastidxid;
When a relation is moved to another tablespace, we can't assume that we can use the old relfilenode in the new tablespace. There might be another relation in the new tablespace with the same relfilenode, so we must generate a fresh relfilenode in the new tablespace. The 8.3 patch to let deleted relation files linger as zero-length files until the next checkpoint made this more obvious: moving a relation from one table space another, and then back again, caused a collision with the lingering file. Back-patch to 8.1. The issue is present in 8.0 as well, but it doesn't seem worth fixing there, because we didn't have protection from OID collisions after OID wraparound before 8.1. Report by Guillaume Lelarge.
2008-10-07 13:15:41 +02:00
Oid newrelfilenode;
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
RelFileNode newrnode;
SMgrRelation dstrel;
Relation pg_class;
HeapTuple tuple;
Form_pg_class rd_rel;
Introduce the concept of relation forks. An smgr relation can now consist of multiple forks, and each fork can be created and grown separately. The bulk of this patch is about changing the smgr API to include an extra ForkNumber argument in every smgr function. Also, smgrscheduleunlink and smgrdounlink no longer implicitly call smgrclose, because other forks might still exist after unlinking one. The callers of those functions have been modified to call smgrclose instead. This patch in itself doesn't have any user-visible effect, but provides the infrastructure needed for upcoming patches. The additional forks envisioned are a rewritten FSM implementation that doesn't rely on a fixed-size shared memory block, and a visibility map to allow skipping portions of a table in VACUUM that have no dead tuples.
2008-08-11 13:05:11 +02:00
ForkNumber forkNum;
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
Change the relation_open protocol so that we obtain lock on a relation (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.
2006-07-31 22:09:10 +02:00
/*
* Need lock here in case we are recursing to toast table or index
*/
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
rel = relation_open(tableOid, lockmode);
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
/*
Create a "relation mapping" infrastructure to support changing the relfilenodes of shared or nailed system catalogs. This has two key benefits: * The new CLUSTER-based VACUUM FULL can be applied safely to all catalogs. * We no longer have to use an unsafe reindex-in-place approach for reindexing shared catalogs. CLUSTER on nailed catalogs now works too, although I left it disabled on shared catalogs because the resulting pg_index.indisclustered update would only be visible in one database. Since reindexing shared system catalogs is now fully transactional and crash-safe, the former special cases in REINDEX behavior have been removed; shared catalogs are treated the same as non-shared. This commit does not do anything about the recently-discussed problem of deadlocks between VACUUM FULL/CLUSTER on a system catalog and other concurrent queries; will address that in a separate patch. As a stopgap, parallel_schedule has been tweaked to run vacuum.sql by itself, to avoid such failures during the regression tests.
2010-02-07 21:48:13 +01:00
* No work if no change in tablespace.
*/
oldTableSpace = rel->rd_rel->reltablespace;
if (newTableSpace == oldTableSpace ||
(newTableSpace == MyDatabaseTableSpace && oldTableSpace == 0))
{
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
InvokeObjectPostAlterHook(RelationRelationId,
RelationGetRelid(rel), 0);
Create a "relation mapping" infrastructure to support changing the relfilenodes of shared or nailed system catalogs. This has two key benefits: * The new CLUSTER-based VACUUM FULL can be applied safely to all catalogs. * We no longer have to use an unsafe reindex-in-place approach for reindexing shared catalogs. CLUSTER on nailed catalogs now works too, although I left it disabled on shared catalogs because the resulting pg_index.indisclustered update would only be visible in one database. Since reindexing shared system catalogs is now fully transactional and crash-safe, the former special cases in REINDEX behavior have been removed; shared catalogs are treated the same as non-shared. This commit does not do anything about the recently-discussed problem of deadlocks between VACUUM FULL/CLUSTER on a system catalog and other concurrent queries; will address that in a separate patch. As a stopgap, parallel_schedule has been tweaked to run vacuum.sql by itself, to avoid such failures during the regression tests.
2010-02-07 21:48:13 +01:00
relation_close(rel, NoLock);
return;
}
/*
* We cannot support moving mapped relations into different tablespaces.
* (In particular this eliminates all shared catalogs.)
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
*/
Create a "relation mapping" infrastructure to support changing the relfilenodes of shared or nailed system catalogs. This has two key benefits: * The new CLUSTER-based VACUUM FULL can be applied safely to all catalogs. * We no longer have to use an unsafe reindex-in-place approach for reindexing shared catalogs. CLUSTER on nailed catalogs now works too, although I left it disabled on shared catalogs because the resulting pg_index.indisclustered update would only be visible in one database. Since reindexing shared system catalogs is now fully transactional and crash-safe, the former special cases in REINDEX behavior have been removed; shared catalogs are treated the same as non-shared. This commit does not do anything about the recently-discussed problem of deadlocks between VACUUM FULL/CLUSTER on a system catalog and other concurrent queries; will address that in a separate patch. As a stopgap, parallel_schedule has been tweaked to run vacuum.sql by itself, to avoid such failures during the regression tests.
2010-02-07 21:48:13 +01:00
if (RelationIsMapped(rel))
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot move system relation \"%s\"",
RelationGetRelationName(rel))));
Remove hack in pg_tablespace_aclmask() that disallowed permissions on pg_global even to superusers, and replace it with checks in various other places to complain about invalid uses of pg_global. This ends up being a bit more code but it allows a more specific error message to be given, and it un-breaks pg_tablespace_size() on pg_global. Per discussion.
2007-10-12 20:55:12 +02:00
/* Can't move a non-shared relation into pg_global */
if (newTableSpace == GLOBALTABLESPACE_OID)
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("only shared relations can be placed in pg_global tablespace")));
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Don't allow moving temp tables of other backends ... their local buffer
* manager is not going to cope.
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
*/
Modify the relcache to record the temp status of both local and nonlocal temp relations; this is no more expensive than before, now that we have pg_class.relistemp. Insert tests into bufmgr.c to prevent attempting to fetch pages from nonlocal temp relations. This provides a low-level defense against bugs-of-omission allowing temp pages to be loaded into shared buffers, as in the contrib/pgstattuple problem reported by Stuart Bishop. While at it, tweak a bunch of places to use new relcache tests (instead of expensive probes into pg_namespace) to detect local or nonlocal temp tables.
2009-04-01 00:12:48 +02:00
if (RELATION_IS_OTHER_TEMP(rel))
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("cannot move temporary tables of other sessions")));
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
reltoastrelid = rel->rd_rel->reltoastrelid;
reltoastidxid = rel->rd_rel->reltoastidxid;
/* Get a modifiable copy of the relation's pg_class row */
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
pg_class = heap_open(RelationRelationId, RowExclusiveLock);
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
Wrap calls to SearchSysCache and related functions using macros. The purpose of this change is to eliminate the need for every caller of SearchSysCache, SearchSysCacheCopy, SearchSysCacheExists, GetSysCacheOid, and SearchSysCacheList to know the maximum number of allowable keys for a syscache entry (currently 4). This will make it far easier to increase the maximum number of keys in a future release should we choose to do so, and it makes the code shorter, too. Design and review by Tom Lane.
2010-02-14 19:42:19 +01:00
tuple = SearchSysCacheCopy1(RELOID, ObjectIdGetDatum(tableOid));
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
if (!HeapTupleIsValid(tuple))
elog(ERROR, "cache lookup failed for relation %u", tableOid);
rd_rel = (Form_pg_class) GETSTRUCT(tuple);
Introduce the concept of relation forks. An smgr relation can now consist of multiple forks, and each fork can be created and grown separately. The bulk of this patch is about changing the smgr API to include an extra ForkNumber argument in every smgr function. Also, smgrscheduleunlink and smgrdounlink no longer implicitly call smgrclose, because other forks might still exist after unlinking one. The callers of those functions have been modified to call smgrclose instead. This patch in itself doesn't have any user-visible effect, but provides the infrastructure needed for upcoming patches. The additional forks envisioned are a rewritten FSM implementation that doesn't rely on a fixed-size shared memory block, and a visibility map to allow skipping portions of a table in VACUUM that have no dead tuples.
2008-08-11 13:05:11 +02:00
/*
* Since we copy the file directly without looking at the shared buffers,
* we'd better first flush out any pages of the source relation that are
* in shared buffers. We assume no new changes will be made while we are
* holding exclusive lock on the rel.
*/
FlushRelationBuffers(rel);
When a relation is moved to another tablespace, we can't assume that we can use the old relfilenode in the new tablespace. There might be another relation in the new tablespace with the same relfilenode, so we must generate a fresh relfilenode in the new tablespace. The 8.3 patch to let deleted relation files linger as zero-length files until the next checkpoint made this more obvious: moving a relation from one table space another, and then back again, caused a collision with the lingering file. Back-patch to 8.1. The issue is present in 8.0 as well, but it doesn't seem worth fixing there, because we didn't have protection from OID collisions after OID wraparound before 8.1. Report by Guillaume Lelarge.
2008-10-07 13:15:41 +02:00
/*
* Relfilenodes are not unique across tablespaces, so we need to allocate
* a new one in the new tablespace.
*/
Generalize concept of temporary relations to "relation persistence". This commit replaces pg_class.relistemp with pg_class.relpersistence; and also modifies the RangeVar node type to carry relpersistence rather than istemp. It also removes removes rd_istemp from RelationData and instead performs the correct computation based on relpersistence. For clarity, we add three new macros: RelationNeedsWAL(), RelationUsesLocalBuffers(), and RelationUsesTempNamespace(), so that we can clarify the purpose of each check that previous depended on rd_istemp. This is intended as infrastructure for the upcoming unlogged tables patch, as well as for future possible work on global temporary tables.
2010-12-13 18:34:26 +01:00
newrelfilenode = GetNewRelFileNode(newTableSpace, NULL,
rel->rd_rel->relpersistence);
When a relation is moved to another tablespace, we can't assume that we can use the old relfilenode in the new tablespace. There might be another relation in the new tablespace with the same relfilenode, so we must generate a fresh relfilenode in the new tablespace. The 8.3 patch to let deleted relation files linger as zero-length files until the next checkpoint made this more obvious: moving a relation from one table space another, and then back again, caused a collision with the lingering file. Back-patch to 8.1. The issue is present in 8.0 as well, but it doesn't seem worth fixing there, because we didn't have protection from OID collisions after OID wraparound before 8.1. Report by Guillaume Lelarge.
2008-10-07 13:15:41 +02:00
Introduce the concept of relation forks. An smgr relation can now consist of multiple forks, and each fork can be created and grown separately. The bulk of this patch is about changing the smgr API to include an extra ForkNumber argument in every smgr function. Also, smgrscheduleunlink and smgrdounlink no longer implicitly call smgrclose, because other forks might still exist after unlinking one. The callers of those functions have been modified to call smgrclose instead. This patch in itself doesn't have any user-visible effect, but provides the infrastructure needed for upcoming patches. The additional forks envisioned are a rewritten FSM implementation that doesn't rely on a fixed-size shared memory block, and a visibility map to allow skipping portions of a table in VACUUM that have no dead tuples.
2008-08-11 13:05:11 +02:00
/* Open old and new relation */
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
newrnode = rel->rd_node;
When a relation is moved to another tablespace, we can't assume that we can use the old relfilenode in the new tablespace. There might be another relation in the new tablespace with the same relfilenode, so we must generate a fresh relfilenode in the new tablespace. The 8.3 patch to let deleted relation files linger as zero-length files until the next checkpoint made this more obvious: moving a relation from one table space another, and then back again, caused a collision with the lingering file. Back-patch to 8.1. The issue is present in 8.0 as well, but it doesn't seem worth fixing there, because we didn't have protection from OID collisions after OID wraparound before 8.1. Report by Guillaume Lelarge.
2008-10-07 13:15:41 +02:00
newrnode.relNode = newrelfilenode;
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
newrnode.spcNode = newTableSpace;
Include the backend ID in the relpath of temporary relations. This allows us to reliably remove all leftover temporary relation files on cluster startup without reference to system catalogs or WAL; therefore, we no longer include temporary relations in XLOG_XACT_COMMIT and XLOG_XACT_ABORT WAL records. Since these changes require including a backend ID in each SharedInvalSmgrMsg, the size of the SharedInvalidationMessage.id field has been reduced from two bytes to one, and the maximum number of connections has been reduced from INT_MAX / 4 to 2^23-1. It would be possible to remove these restrictions by increasing the size of SharedInvalidationMessage by 4 bytes, but right now that doesn't seem like a good trade-off. Review by Jaime Casanova and Tom Lane.
2010-08-13 22:10:54 +02:00
dstrel = smgropen(newrnode, rel->rd_backend);
Change order of operations in ALTER TABLE SET TABLESPACE so that we don't hold an open file reference to the original table at the end. This is a good thing in any case, particularly so on Windows which cannot drop the table file otherwise.
2004-08-13 06:50:28 +02:00
Phase 1 of fix for 'SMgrRelation hashtable corrupted' problem. This is the minimum required fix. I want to look next at taking advantage of it by simplifying the message semantics in the shared inval message queue, but that part can be held over for 8.1 if it turns out too ugly.
2005-01-10 21:02:24 +01:00
RelationOpenSmgr(rel);
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
/*
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* Create and copy all forks of the relation, and schedule unlinking of
* old physical files.
Introduce the concept of relation forks. An smgr relation can now consist of multiple forks, and each fork can be created and grown separately. The bulk of this patch is about changing the smgr API to include an extra ForkNumber argument in every smgr function. Also, smgrscheduleunlink and smgrdounlink no longer implicitly call smgrclose, because other forks might still exist after unlinking one. The callers of those functions have been modified to call smgrclose instead. This patch in itself doesn't have any user-visible effect, but provides the infrastructure needed for upcoming patches. The additional forks envisioned are a rewritten FSM implementation that doesn't rely on a fixed-size shared memory block, and a visibility map to allow skipping portions of a table in VACUUM that have no dead tuples.
2008-08-11 13:05:11 +02:00
*
* NOTE: any conflict in relfilenode value will be caught in
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* RelationCreateStorage().
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
*/
Generalize concept of temporary relations to "relation persistence". This commit replaces pg_class.relistemp with pg_class.relpersistence; and also modifies the RangeVar node type to carry relpersistence rather than istemp. It also removes removes rd_istemp from RelationData and instead performs the correct computation based on relpersistence. For clarity, we add three new macros: RelationNeedsWAL(), RelationUsesLocalBuffers(), and RelationUsesTempNamespace(), so that we can clarify the purpose of each check that previous depended on rd_istemp. This is intended as infrastructure for the upcoming unlogged tables patch, as well as for future possible work on global temporary tables.
2010-12-13 18:34:26 +01:00
RelationCreateStorage(newrnode, rel->rd_rel->relpersistence);
Rethink the way FSM truncation works. Instead of WAL-logging FSM truncations in FSM code, call FreeSpaceMapTruncateRel from smgr_redo. To make that cleaner from modularity point of view, move the WAL-logging one level up to RelationTruncate, and move RelationTruncate and all the related WAL-logging to new src/backend/catalog/storage.c file. Introduce new RelationCreateStorage and RelationDropStorage functions that are used instead of calling smgrcreate/smgrscheduleunlink directly. Move the pending rel deletion stuff from smgrcreate/smgrscheduleunlink to the new functions. This leaves smgr.c as a thin wrapper around md.c; all the transactional stuff is now in storage.c. This will make it easier to add new forks with similar truncation logic, like the visibility map.
2008-11-19 11:34:52 +01:00
/* copy main fork */
Generalize concept of temporary relations to "relation persistence". This commit replaces pg_class.relistemp with pg_class.relpersistence; and also modifies the RangeVar node type to carry relpersistence rather than istemp. It also removes removes rd_istemp from RelationData and instead performs the correct computation based on relpersistence. For clarity, we add three new macros: RelationNeedsWAL(), RelationUsesLocalBuffers(), and RelationUsesTempNamespace(), so that we can clarify the purpose of each check that previous depended on rd_istemp. This is intended as infrastructure for the upcoming unlogged tables patch, as well as for future possible work on global temporary tables.
2010-12-13 18:34:26 +01:00
copy_relation_data(rel->rd_smgr, dstrel, MAIN_FORKNUM,
rel->rd_rel->relpersistence);
Rethink the way FSM truncation works. Instead of WAL-logging FSM truncations in FSM code, call FreeSpaceMapTruncateRel from smgr_redo. To make that cleaner from modularity point of view, move the WAL-logging one level up to RelationTruncate, and move RelationTruncate and all the related WAL-logging to new src/backend/catalog/storage.c file. Introduce new RelationCreateStorage and RelationDropStorage functions that are used instead of calling smgrcreate/smgrscheduleunlink directly. Move the pending rel deletion stuff from smgrcreate/smgrscheduleunlink to the new functions. This leaves smgr.c as a thin wrapper around md.c; all the transactional stuff is now in storage.c. This will make it easier to add new forks with similar truncation logic, like the visibility map.
2008-11-19 11:34:52 +01:00
/* copy those extra forks that exist */
for (forkNum = MAIN_FORKNUM + 1; forkNum <= MAX_FORKNUM; forkNum++)
Introduce the concept of relation forks. An smgr relation can now consist of multiple forks, and each fork can be created and grown separately. The bulk of this patch is about changing the smgr API to include an extra ForkNumber argument in every smgr function. Also, smgrscheduleunlink and smgrdounlink no longer implicitly call smgrclose, because other forks might still exist after unlinking one. The callers of those functions have been modified to call smgrclose instead. This patch in itself doesn't have any user-visible effect, but provides the infrastructure needed for upcoming patches. The additional forks envisioned are a rewritten FSM implementation that doesn't rely on a fixed-size shared memory block, and a visibility map to allow skipping portions of a table in VACUUM that have no dead tuples.
2008-08-11 13:05:11 +02:00
{
if (smgrexists(rel->rd_smgr, forkNum))
{
Rethink the way FSM truncation works. Instead of WAL-logging FSM truncations in FSM code, call FreeSpaceMapTruncateRel from smgr_redo. To make that cleaner from modularity point of view, move the WAL-logging one level up to RelationTruncate, and move RelationTruncate and all the related WAL-logging to new src/backend/catalog/storage.c file. Introduce new RelationCreateStorage and RelationDropStorage functions that are used instead of calling smgrcreate/smgrscheduleunlink directly. Move the pending rel deletion stuff from smgrcreate/smgrscheduleunlink to the new functions. This leaves smgr.c as a thin wrapper around md.c; all the transactional stuff is now in storage.c. This will make it easier to add new forks with similar truncation logic, like the visibility map.
2008-11-19 11:34:52 +01:00
smgrcreate(dstrel, forkNum, false);
Generalize concept of temporary relations to "relation persistence". This commit replaces pg_class.relistemp with pg_class.relpersistence; and also modifies the RangeVar node type to carry relpersistence rather than istemp. It also removes removes rd_istemp from RelationData and instead performs the correct computation based on relpersistence. For clarity, we add three new macros: RelationNeedsWAL(), RelationUsesLocalBuffers(), and RelationUsesTempNamespace(), so that we can clarify the purpose of each check that previous depended on rd_istemp. This is intended as infrastructure for the upcoming unlogged tables patch, as well as for future possible work on global temporary tables.
2010-12-13 18:34:26 +01:00
copy_relation_data(rel->rd_smgr, dstrel, forkNum,
rel->rd_rel->relpersistence);
Introduce the concept of relation forks. An smgr relation can now consist of multiple forks, and each fork can be created and grown separately. The bulk of this patch is about changing the smgr API to include an extra ForkNumber argument in every smgr function. Also, smgrscheduleunlink and smgrdounlink no longer implicitly call smgrclose, because other forks might still exist after unlinking one. The callers of those functions have been modified to call smgrclose instead. This patch in itself doesn't have any user-visible effect, but provides the infrastructure needed for upcoming patches. The additional forks envisioned are a rewritten FSM implementation that doesn't rely on a fixed-size shared memory block, and a visibility map to allow skipping portions of a table in VACUUM that have no dead tuples.
2008-08-11 13:05:11 +02:00
}
}
Rethink the way FSM truncation works. Instead of WAL-logging FSM truncations in FSM code, call FreeSpaceMapTruncateRel from smgr_redo. To make that cleaner from modularity point of view, move the WAL-logging one level up to RelationTruncate, and move RelationTruncate and all the related WAL-logging to new src/backend/catalog/storage.c file. Introduce new RelationCreateStorage and RelationDropStorage functions that are used instead of calling smgrcreate/smgrscheduleunlink directly. Move the pending rel deletion stuff from smgrcreate/smgrscheduleunlink to the new functions. This leaves smgr.c as a thin wrapper around md.c; all the transactional stuff is now in storage.c. This will make it easier to add new forks with similar truncation logic, like the visibility map.
2008-11-19 11:34:52 +01:00
/* drop old relation, and close new one */
RelationDropStorage(rel);
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
smgrclose(dstrel);
/* update the pg_class row */
rd_rel->reltablespace = (newTableSpace == MyDatabaseTableSpace) ? InvalidOid : newTableSpace;
When a relation is moved to another tablespace, we can't assume that we can use the old relfilenode in the new tablespace. There might be another relation in the new tablespace with the same relfilenode, so we must generate a fresh relfilenode in the new tablespace. The 8.3 patch to let deleted relation files linger as zero-length files until the next checkpoint made this more obvious: moving a relation from one table space another, and then back again, caused a collision with the lingering file. Back-patch to 8.1. The issue is present in 8.0 as well, but it doesn't seem worth fixing there, because we didn't have protection from OID collisions after OID wraparound before 8.1. Report by Guillaume Lelarge.
2008-10-07 13:15:41 +02:00
rd_rel->relfilenode = newrelfilenode;
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
simple_heap_update(pg_class, &tuple->t_self, tuple);
CatalogUpdateIndexes(pg_class, tuple);
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
InvokeObjectPostAlterHook(RelationRelationId, RelationGetRelid(rel), 0);
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
heap_freetuple(tuple);
heap_close(pg_class, RowExclusiveLock);
relation_close(rel, NoLock);
/* Make sure the reltablespace change is visible */
CommandCounterIncrement();
/* Move associated toast relation and/or index, too */
if (OidIsValid(reltoastrelid))
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecSetTableSpace(reltoastrelid, newTableSpace, lockmode);
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
if (OidIsValid(reltoastidxid))
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecSetTableSpace(reltoastidxid, newTableSpace, lockmode);
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
}
/*
* Copy data, block by block
*/
static void
Introduce the concept of relation forks. An smgr relation can now consist of multiple forks, and each fork can be created and grown separately. The bulk of this patch is about changing the smgr API to include an extra ForkNumber argument in every smgr function. Also, smgrscheduleunlink and smgrdounlink no longer implicitly call smgrclose, because other forks might still exist after unlinking one. The callers of those functions have been modified to call smgrclose instead. This patch in itself doesn't have any user-visible effect, but provides the infrastructure needed for upcoming patches. The additional forks envisioned are a rewritten FSM implementation that doesn't rely on a fixed-size shared memory block, and a visibility map to allow skipping portions of a table in VACUUM that have no dead tuples.
2008-08-11 13:05:11 +02:00
copy_relation_data(SMgrRelation src, SMgrRelation dst,
Generalize concept of temporary relations to "relation persistence". This commit replaces pg_class.relistemp with pg_class.relpersistence; and also modifies the RangeVar node type to carry relpersistence rather than istemp. It also removes removes rd_istemp from RelationData and instead performs the correct computation based on relpersistence. For clarity, we add three new macros: RelationNeedsWAL(), RelationUsesLocalBuffers(), and RelationUsesTempNamespace(), so that we can clarify the purpose of each check that previous depended on rd_istemp. This is intended as infrastructure for the upcoming unlogged tables patch, as well as for future possible work on global temporary tables.
2010-12-13 18:34:26 +01:00
ForkNumber forkNum, char relpersistence)
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
{
Fix another longstanding problem in copy_relation_data: it was blithely assuming that a local char[] array would be aligned on at least a word boundary. There are architectures on which that is pretty much guaranteed to NOT be the case ... and those arches also don't like non-aligned memory accesses, meaning that log_newpage() would crash if it ever got invoked. Even on Intel-ish machines there's a potential for a large performance penalty from doing I/O to an inadequately aligned buffer. So palloc it instead. Backpatch to 8.0 --- 7.4 doesn't have this code.
2010-07-29 21:23:20 +02:00
char *buf;
Page page;
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
bool use_wal;
BlockNumber nblocks;
BlockNumber blkno;
Fix another longstanding problem in copy_relation_data: it was blithely assuming that a local char[] array would be aligned on at least a word boundary. There are architectures on which that is pretty much guaranteed to NOT be the case ... and those arches also don't like non-aligned memory accesses, meaning that log_newpage() would crash if it ever got invoked. Even on Intel-ish machines there's a potential for a large performance penalty from doing I/O to an inadequately aligned buffer. So palloc it instead. Backpatch to 8.0 --- 7.4 doesn't have this code.
2010-07-29 21:23:20 +02:00
/*
* palloc the buffer so that it's MAXALIGN'd. If it were just a local
* char[] array, the compiler might align it on any byte boundary, which
* can seriously hurt transfer speed to and from the kernel; not to
* mention possibly making log_newpage's accesses to the page header fail.
*/
buf = (char *) palloc(BLCKSZ);
page = (Page) buf;
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
/*
Introduce Streaming Replication. This includes two new kinds of postmaster processes, walsenders and walreceiver. Walreceiver is responsible for connecting to the primary server and streaming WAL to disk, while walsender runs in the primary server and streams WAL from disk to the client. Documentation still needs work, but the basics are there. We will probably pull the replication section to a new chapter later on, as well as the sections describing file-based replication. But let's do that as a separate patch, so that it's easier to see what has been added/changed. This patch also adds a new section to the chapter about FE/BE protocol, documenting the protocol used by walsender/walreceivxer. Bump catalog version because of two new functions, pg_last_xlog_receive_location() and pg_last_xlog_replay_location(), for monitoring the progress of replication. Fujii Masao, with additional hacking by me
2010-01-15 10:19:10 +01:00
* We need to log the copied data in WAL iff WAL archiving/streaming is
Generalize concept of temporary relations to "relation persistence". This commit replaces pg_class.relistemp with pg_class.relpersistence; and also modifies the RangeVar node type to carry relpersistence rather than istemp. It also removes removes rd_istemp from RelationData and instead performs the correct computation based on relpersistence. For clarity, we add three new macros: RelationNeedsWAL(), RelationUsesLocalBuffers(), and RelationUsesTempNamespace(), so that we can clarify the purpose of each check that previous depended on rd_istemp. This is intended as infrastructure for the upcoming unlogged tables patch, as well as for future possible work on global temporary tables.
2010-12-13 18:34:26 +01:00
* enabled AND it's a permanent relation.
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
*/
Generalize concept of temporary relations to "relation persistence". This commit replaces pg_class.relistemp with pg_class.relpersistence; and also modifies the RangeVar node type to carry relpersistence rather than istemp. It also removes removes rd_istemp from RelationData and instead performs the correct computation based on relpersistence. For clarity, we add three new macros: RelationNeedsWAL(), RelationUsesLocalBuffers(), and RelationUsesTempNamespace(), so that we can clarify the purpose of each check that previous depended on rd_istemp. This is intended as infrastructure for the upcoming unlogged tables patch, as well as for future possible work on global temporary tables.
2010-12-13 18:34:26 +01:00
use_wal = XLogIsNeeded() && relpersistence == RELPERSISTENCE_PERMANENT;
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
Introduce the concept of relation forks. An smgr relation can now consist of multiple forks, and each fork can be created and grown separately. The bulk of this patch is about changing the smgr API to include an extra ForkNumber argument in every smgr function. Also, smgrscheduleunlink and smgrdounlink no longer implicitly call smgrclose, because other forks might still exist after unlinking one. The callers of those functions have been modified to call smgrclose instead. This patch in itself doesn't have any user-visible effect, but provides the infrastructure needed for upcoming patches. The additional forks envisioned are a rewritten FSM implementation that doesn't rely on a fixed-size shared memory block, and a visibility map to allow skipping portions of a table in VACUUM that have no dead tuples.
2008-08-11 13:05:11 +02:00
nblocks = smgrnblocks(src, forkNum);
copy_relation_data was mistakenly assuming that the source relation would always be already open at the smgr level. Per bug report from Fabien Coelho.
2004-08-31 17:56:39 +02:00
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
for (blkno = 0; blkno < nblocks; blkno++)
{
pgindent run for 9.0, second run
2010-07-06 21:19:02 +02:00
/* If we got a cancel signal during the copy of the data, quit */
CHECK_FOR_INTERRUPTS();
Introduce the concept of relation forks. An smgr relation can now consist of multiple forks, and each fork can be created and grown separately. The bulk of this patch is about changing the smgr API to include an extra ForkNumber argument in every smgr function. Also, smgrscheduleunlink and smgrdounlink no longer implicitly call smgrclose, because other forks might still exist after unlinking one. The callers of those functions have been modified to call smgrclose instead. This patch in itself doesn't have any user-visible effect, but provides the infrastructure needed for upcoming patches. The additional forks envisioned are a rewritten FSM implementation that doesn't rely on a fixed-size shared memory block, and a visibility map to allow skipping portions of a table in VACUUM that have no dead tuples.
2008-08-11 13:05:11 +02:00
smgrread(src, forkNum, blkno, buf);
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
Fix checksums for CLUSTER, VACUUM FULL etc. In CLUSTER, VACUUM FULL and ALTER TABLE SET TABLESPACE I erroneously set checksum before log_newpage, which sets the LSN and invalidates the checksum. So set checksum immediately *after* log_newpage. Bug report Fujii Masao, Fix and patch by Jeff Davis
2013-04-07 23:16:51 +02:00
if (!PageIsVerified(page, blkno))
ereport(ERROR,
(errcode(ERRCODE_DATA_CORRUPTED),
errmsg("invalid page in block %u of relation %s",
blkno,
relpathbackend(src->smgr_rnode.node,
src->smgr_rnode.backend,
forkNum))));
Allow I/O reliability checks using 16-bit checksums Checksums are set immediately prior to flush out of shared buffers and checked when pages are read in again. Hint bit setting will require full page write when block is dirtied, which causes various infrastructure changes. Extensive comments, docs and README. WARNING message thrown if checksum fails on non-all zeroes page; ERROR thrown but can be disabled with ignore_checksum_failure = on. Feature enabled by an initdb option, since transition from option off to option on is long and complex and has not yet been implemented. Default is not to use checksums. Checksum used is WAL CRC-32 truncated to 16-bits. Simon Riggs, Jeff Davis, Greg Smith Wide input and assistance from many community members. Thank you.
2013-03-22 14:54:07 +01:00
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
/* XLOG stuff */
if (use_wal)
Include the backend ID in the relpath of temporary relations. This allows us to reliably remove all leftover temporary relation files on cluster startup without reference to system catalogs or WAL; therefore, we no longer include temporary relations in XLOG_XACT_COMMIT and XLOG_XACT_ABORT WAL records. Since these changes require including a backend ID in each SharedInvalSmgrMsg, the size of the SharedInvalidationMessage.id field has been reduced from two bytes to one, and the maximum number of connections has been reduced from INT_MAX / 4 to 2^23-1. It would be possible to remove these restrictions by increasing the size of SharedInvalidationMessage by 4 bytes, but right now that doesn't seem like a good trade-off. Review by Jaime Casanova and Tom Lane.
2010-08-13 22:10:54 +02:00
log_newpage(&dst->smgr_rnode.node, forkNum, blkno, page);
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
Fix checksums for CLUSTER, VACUUM FULL etc. In CLUSTER, VACUUM FULL and ALTER TABLE SET TABLESPACE I erroneously set checksum before log_newpage, which sets the LSN and invalidates the checksum. So set checksum immediately *after* log_newpage. Bug report Fujii Masao, Fix and patch by Jeff Davis
2013-04-07 23:16:51 +02:00
PageSetChecksumInplace(page, blkno);
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Now write the page. We say isTemp = true even if it's not a temp
* rel, because there's no need for smgr to schedule an fsync for this
* write; we'll do it ourselves below.
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
*/
Introduce the concept of relation forks. An smgr relation can now consist of multiple forks, and each fork can be created and grown separately. The bulk of this patch is about changing the smgr API to include an extra ForkNumber argument in every smgr function. Also, smgrscheduleunlink and smgrdounlink no longer implicitly call smgrclose, because other forks might still exist after unlinking one. The callers of those functions have been modified to call smgrclose instead. This patch in itself doesn't have any user-visible effect, but provides the infrastructure needed for upcoming patches. The additional forks envisioned are a rewritten FSM implementation that doesn't rely on a fixed-size shared memory block, and a visibility map to allow skipping portions of a table in VACUUM that have no dead tuples.
2008-08-11 13:05:11 +02:00
smgrextend(dst, forkNum, blkno, buf, true);
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
}
Fix another longstanding problem in copy_relation_data: it was blithely assuming that a local char[] array would be aligned on at least a word boundary. There are architectures on which that is pretty much guaranteed to NOT be the case ... and those arches also don't like non-aligned memory accesses, meaning that log_newpage() would crash if it ever got invoked. Even on Intel-ish machines there's a potential for a large performance penalty from doing I/O to an inadequately aligned buffer. So palloc it instead. Backpatch to 8.0 --- 7.4 doesn't have this code.
2010-07-29 21:23:20 +02:00
pfree(buf);
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
/*
Comment fixes. Jeff Davis, somewhat edited by me
2012-08-30 16:42:28 +02:00
* If the rel is WAL-logged, must fsync before commit. We use heap_sync
* to ensure that the toast table gets fsync'd too. (For a temp or
* unlogged rel we don't care since the data will be gone after a crash
* anyway.)
Dept. of further reflection: I looked around to see if any other callers of XLogInsert had the same sort of checkpoint interlock problem as RecordTransactionCommit, and indeed I found some. Btree index build and ALTER TABLE SET TABLESPACE write data outside the friendly confines of the buffer manager, and therefore they have to take their own responsibility for checkpoint interlock. The easiest solution seems to be to force smgrimmedsync at the end of the index build or table copy, even when the operation is being WAL-logged. This is sufficient since the new index or table will be of interest to no one if we don't get as far as committing the current transaction.
2004-08-16 01:44:46 +02:00
*
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
* It's obvious that we must do this when not WAL-logging the copy. It's
* less obvious that we have to do it even if we did WAL-log the copied
* pages. The reason is that since we're copying outside shared buffers, a
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* CHECKPOINT occurring during the copy has no way to flush the previously
* written data to disk (indeed it won't know the new rel even exists). A
* crash later on would replay WAL from the checkpoint, therefore it
* wouldn't replay our earlier WAL entries. If we do not fsync those pages
* here, they might still not be on disk when the crash occurs.
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
*/
Generalize concept of temporary relations to "relation persistence". This commit replaces pg_class.relistemp with pg_class.relpersistence; and also modifies the RangeVar node type to carry relpersistence rather than istemp. It also removes removes rd_istemp from RelationData and instead performs the correct computation based on relpersistence. For clarity, we add three new macros: RelationNeedsWAL(), RelationUsesLocalBuffers(), and RelationUsesTempNamespace(), so that we can clarify the purpose of each check that previous depended on rd_istemp. This is intended as infrastructure for the upcoming unlogged tables patch, as well as for future possible work on global temporary tables.
2010-12-13 18:34:26 +01:00
if (relpersistence == RELPERSISTENCE_PERMANENT)
Introduce the concept of relation forks. An smgr relation can now consist of multiple forks, and each fork can be created and grown separately. The bulk of this patch is about changing the smgr API to include an extra ForkNumber argument in every smgr function. Also, smgrscheduleunlink and smgrdounlink no longer implicitly call smgrclose, because other forks might still exist after unlinking one. The callers of those functions have been modified to call smgrclose instead. This patch in itself doesn't have any user-visible effect, but provides the infrastructure needed for upcoming patches. The additional forks envisioned are a rewritten FSM implementation that doesn't rely on a fixed-size shared memory block, and a visibility map to allow skipping portions of a table in VACUUM that have no dead tuples.
2008-08-11 13:05:11 +02:00
smgrimmedsync(dst, forkNum);
ALTER TABLE SET TABLESPACE. Gavin Sherry, some rework by Tom Lane.
2004-07-12 01:13:58 +02:00
}
OK, here's the final version of ALTER TABLE ... SET WITHOUT CLUSTER. Has docs + regression test. Christopher Kings-Lynne
2004-06-02 23:01:10 +02:00
Add ALTER TABLE ENABLE/DISABLE TRIGGER commands. Change pg_dump to use these instead of its previous hack of changing pg_class.reltriggers. Documentation is lacking, will add that later. Patch by Satoshi Nagayasu, review and some extra work by Tom Lane.
2005-08-24 00:40:47 +02:00
/*
* ALTER TABLE ENABLE/DISABLE TRIGGER
*
* We just pass this off to trigger.c.
*/
static void
ATExecEnableDisableTrigger(Relation rel, char *trigname,
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
char fires_when, bool skip_system, LOCKMODE lockmode)
Changes pg_trigger and extend pg_rewrite in order to allow triggers and 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
2007-03-20 00:38:32 +01:00
{
EnableDisableTrigger(rel, trigname, fires_when, skip_system);
}
/*
* ALTER TABLE ENABLE/DISABLE RULE
*
* We just pass this off to rewriteDefine.c.
*/
static void
ATExecEnableDisableRule(Relation rel, char *trigname,
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
char fires_when, LOCKMODE lockmode)
Add ALTER TABLE ENABLE/DISABLE TRIGGER commands. Change pg_dump to use these instead of its previous hack of changing pg_class.reltriggers. Documentation is lacking, will add that later. Patch by Satoshi Nagayasu, review and some extra work by Tom Lane.
2005-08-24 00:40:47 +02:00
{
Changes pg_trigger and extend pg_rewrite in order to allow triggers and 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
2007-03-20 00:38:32 +01:00
EnableDisableRule(rel, trigname, fires_when);
Add ALTER TABLE ENABLE/DISABLE TRIGGER commands. Change pg_dump to use these instead of its previous hack of changing pg_class.reltriggers. Documentation is lacking, will add that later. Patch by Satoshi Nagayasu, review and some extra work by Tom Lane.
2005-08-24 00:40:47 +02:00
}
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
/*
* ALTER TABLE INHERIT
*
* Add a parent to the child's parents. This verifies that all the columns and
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
* check constraints of the parent appear in the child and that they have the
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
* same data types and expressions.
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
*/
Add more checks against altering typed tables - Prohibit altering column type - Prohibit changing inheritance - Move checks from Exec to Prep phases in ALTER TABLE code backpatched to 9.0
2010-07-23 22:04:18 +02:00
static void
ATPrepAddInherit(Relation child_rel)
{
if (child_rel->rd_rel->reloftype)
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("cannot change inheritance of typed table")));
}
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
static void
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecAddInherit(Relation child_rel, RangeVar *parent, LOCKMODE lockmode)
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
{
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
Relation parent_rel,
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
catalogRelation;
SysScanDesc scan;
ScanKeyData key;
HeapTuple inheritsTuple;
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
int32 inhseqno;
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
List *children;
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
/*
Fix possible "tuple concurrently updated" error in ALTER TABLE. 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.
2011-03-19 03:09:57 +01:00
* A self-exclusive lock is needed here. See the similar case in
* MergeAttributes() for a full explanation.
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
*/
Fix possible "tuple concurrently updated" error in ALTER TABLE. 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.
2011-03-19 03:09:57 +01:00
parent_rel = heap_openrv(parent, ShareUpdateExclusiveLock);
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
/*
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
* Must be owner of both parent and child -- child was checked by
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
* ATSimplePermissions call in ATPrepCmd
*/
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
ATSimplePermissions(parent_rel, ATT_TABLE);
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
/* Permanent rels cannot inherit from temporary ones */
Fix failure to ignore leftover temp tables after a server crash. During crash recovery, we remove disk files belonging to temporary tables, but the system catalog entries for such tables are intentionally not cleaned up right away. Instead, the first backend that uses a temp schema is expected to clean out any leftover objects therein. This approach requires that we be careful to ignore leftover temp tables (since any actual access attempt would fail), *even if their BackendId matches our session*, if we have not yet established use of the session's corresponding temp schema. That worked fine in the past, but was broken by commit debcec7dc31a992703911a9953e299c8d730c778 which incorrectly removed the rd_islocaltemp relcache flag. Put it back, and undo various changes that substituted tests like "rel->rd_backend == MyBackendId" for use of a state-aware flag. Per trouble report from Heikki Linnakangas. Back-patch to 9.1 where the erroneous change was made. In the back branches, be careful to add rd_islocaltemp in a spot in the struct that was alignment padding before, so as not to break existing add-on code.
2012-12-18 02:15:32 +01:00
if (parent_rel->rd_rel->relpersistence == RELPERSISTENCE_TEMP &&
child_rel->rd_rel->relpersistence != RELPERSISTENCE_TEMP)
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("cannot inherit from temporary relation \"%s\"",
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
RelationGetRelationName(parent_rel))));
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
Fix failure to ignore leftover temp tables after a server crash. During crash recovery, we remove disk files belonging to temporary tables, but the system catalog entries for such tables are intentionally not cleaned up right away. Instead, the first backend that uses a temp schema is expected to clean out any leftover objects therein. This approach requires that we be careful to ignore leftover temp tables (since any actual access attempt would fail), *even if their BackendId matches our session*, if we have not yet established use of the session's corresponding temp schema. That worked fine in the past, but was broken by commit debcec7dc31a992703911a9953e299c8d730c778 which incorrectly removed the rd_islocaltemp relcache flag. Put it back, and undo various changes that substituted tests like "rel->rd_backend == MyBackendId" for use of a state-aware flag. Per trouble report from Heikki Linnakangas. Back-patch to 9.1 where the erroneous change was made. In the back branches, be careful to add rd_islocaltemp in a spot in the struct that was alignment padding before, so as not to break existing add-on code.
2012-12-18 02:15:32 +01:00
/* If parent rel is temp, it must belong to this session */
if (parent_rel->rd_rel->relpersistence == RELPERSISTENCE_TEMP &&
!parent_rel->rd_islocaltemp)
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
pgindent run for release 9.3 This is the first run of the Perl-based pgindent script. Also update pgindent instructions.
2013-05-29 22:58:43 +02:00
errmsg("cannot inherit from temporary relation of another session")));
Fix failure to ignore leftover temp tables after a server crash. During crash recovery, we remove disk files belonging to temporary tables, but the system catalog entries for such tables are intentionally not cleaned up right away. Instead, the first backend that uses a temp schema is expected to clean out any leftover objects therein. This approach requires that we be careful to ignore leftover temp tables (since any actual access attempt would fail), *even if their BackendId matches our session*, if we have not yet established use of the session's corresponding temp schema. That worked fine in the past, but was broken by commit debcec7dc31a992703911a9953e299c8d730c778 which incorrectly removed the rd_islocaltemp relcache flag. Put it back, and undo various changes that substituted tests like "rel->rd_backend == MyBackendId" for use of a state-aware flag. Per trouble report from Heikki Linnakangas. Back-patch to 9.1 where the erroneous change was made. In the back branches, be careful to add rd_islocaltemp in a spot in the struct that was alignment padding before, so as not to break existing add-on code.
2012-12-18 02:15:32 +01:00
/* Ditto for the child */
if (child_rel->rd_rel->relpersistence == RELPERSISTENCE_TEMP &&
!child_rel->rd_islocaltemp)
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
pgindent run for release 9.3 This is the first run of the Perl-based pgindent script. Also update pgindent instructions.
2013-05-29 22:58:43 +02:00
errmsg("cannot inherit to temporary relation of another session")));
Fix failure to ignore leftover temp tables after a server crash. During crash recovery, we remove disk files belonging to temporary tables, but the system catalog entries for such tables are intentionally not cleaned up right away. Instead, the first backend that uses a temp schema is expected to clean out any leftover objects therein. This approach requires that we be careful to ignore leftover temp tables (since any actual access attempt would fail), *even if their BackendId matches our session*, if we have not yet established use of the session's corresponding temp schema. That worked fine in the past, but was broken by commit debcec7dc31a992703911a9953e299c8d730c778 which incorrectly removed the rd_islocaltemp relcache flag. Put it back, and undo various changes that substituted tests like "rel->rd_backend == MyBackendId" for use of a state-aware flag. Per trouble report from Heikki Linnakangas. Back-patch to 9.1 where the erroneous change was made. In the back branches, be careful to add rd_islocaltemp in a spot in the struct that was alignment padding before, so as not to break existing add-on code.
2012-12-18 02:15:32 +01:00
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
/*
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
* Check for duplicates in the list of parents, and determine the highest
* inhseqno already present; we'll use the next one for the new parent.
* (Note: get RowExclusiveLock because we will write pg_inherits below.)
*
* Note: we do not reject the case where the child already inherits from
* the parent indirectly; CREATE TABLE doesn't reject comparable cases.
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
*/
catalogRelation = heap_open(InheritsRelationId, RowExclusiveLock);
ScanKeyInit(&key,
Anum_pg_inherits_inhrelid,
BTEqualStrategyNumber, F_OIDEQ,
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
ObjectIdGetDatum(RelationGetRelid(child_rel)));
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
scan = systable_beginscan(catalogRelation, InheritsRelidSeqnoIndexId,
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
true, SnapshotNow, 1, &key);
/* inhseqno sequences start at 1 */
inhseqno = 0;
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
while (HeapTupleIsValid(inheritsTuple = systable_getnext(scan)))
{
Form_pg_inherits inh = (Form_pg_inherits) GETSTRUCT(inheritsTuple);
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
if (inh->inhparent == RelationGetRelid(parent_rel))
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
ereport(ERROR,
(errcode(ERRCODE_DUPLICATE_TABLE),
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
errmsg("relation \"%s\" would be inherited from more than once",
RelationGetRelationName(parent_rel))));
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
if (inh->inhseqno > inhseqno)
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
inhseqno = inh->inhseqno;
}
systable_endscan(scan);
/*
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
* Prevent circularity by seeing if proposed parent inherits from child.
* (In particular, this disallows making a rel inherit from itself.)
*
* This is not completely bulletproof because of race conditions: in
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* multi-level inheritance trees, someone else could concurrently be
* making another inheritance link that closes the loop but does not join
* either of the rels we have locked. Preventing that seems to require
* exclusive locks on the entire inheritance tree, which is a cure worse
* than the disease. find_all_inheritors() will cope with circularity
* anyway, so don't sweat it too much.
Modify find_inheritance_children() and find_all_inheritors() to add the ability to lock relations as they scan pg_inherits, and to ignore any relations that have disappeared by the time we get lock on them. This makes uses of these functions safe against concurrent DROP operations on child tables: we will effectively ignore any just-dropped child, rather than possibly throwing an error as in recent bug report from Thomas Johansson (and similar past complaints). The behavior should not change otherwise, since the code was acquiring those same locks anyway, just a little bit later. An exception is LockTableCommand(), which is still behaving unsafely; but that seems to require some more discussion before we change it.
2009-05-12 05:11:02 +02:00
*
* We use weakest lock we can on child's children, namely AccessShareLock.
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
*/
Modify find_inheritance_children() and find_all_inheritors() to add the ability to lock relations as they scan pg_inherits, and to ignore any relations that have disappeared by the time we get lock on them. This makes uses of these functions safe against concurrent DROP operations on child tables: we will effectively ignore any just-dropped child, rather than possibly throwing an error as in recent bug report from Thomas Johansson (and similar past complaints). The behavior should not change otherwise, since the code was acquiring those same locks anyway, just a little bit later. An exception is LockTableCommand(), which is still behaving unsafely; but that seems to require some more discussion before we change it.
2009-05-12 05:11:02 +02:00
children = find_all_inheritors(RelationGetRelid(child_rel),
Tighten integrity checks on ALTER TABLE ... ALTER COLUMN ... RENAME. When a column is renamed, we recursively rename the same column in all descendent tables. But if one of those tables also inherits that column from a table outside the inheritance hierarchy rooted at the named table, we must throw an error. The previous coding correctly prohibited the rename when the parent had inherited the column from elsewhere, but overlooked the case where the parent was OK but a child table also inherited the same column from a second, unrelated parent. For now, not backpatched due to lack of complaints from the field. KaiGai Kohei, with further changes by me. Reviewed by Bernd Helme and Tom Lane.
2010-02-01 20:28:56 +01:00
AccessShareLock, NULL);
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
if (list_member_oid(children, RelationGetRelid(parent_rel)))
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
ereport(ERROR,
(errcode(ERRCODE_DUPLICATE_TABLE),
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
errmsg("circular inheritance not allowed"),
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
errdetail("\"%s\" is already a child of \"%s\".",
parent->relname,
RelationGetRelationName(child_rel))));
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
/* If parent has OIDs then child must have OIDs */
if (parent_rel->rd_rel->relhasoids && !child_rel->rd_rel->relhasoids)
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("table \"%s\" without OIDs cannot inherit from table \"%s\" with OIDs",
RelationGetRelationName(child_rel),
RelationGetRelationName(parent_rel))));
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
/* Match up the columns and bump attinhcount as needed */
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
MergeAttributesIntoExisting(child_rel, parent_rel);
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
/* Match up the constraints and bump coninhcount as needed */
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
MergeConstraintsIntoExisting(child_rel, parent_rel);
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
/*
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* OK, it looks valid. Make the catalog entries that show inheritance.
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
*/
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
StoreCatalogInheritance1(RelationGetRelid(child_rel),
RelationGetRelid(parent_rel),
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
inhseqno + 1,
catalogRelation);
/* Now we're done with pg_inherits */
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
heap_close(catalogRelation, RowExclusiveLock);
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
/* keep our lock on the parent relation until commit */
heap_close(parent_rel, NoLock);
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
}
/*
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
* Obtain the source-text form of the constraint expression for a check
* constraint, given its pg_constraint tuple
*/
static char *
decompile_conbin(HeapTuple contup, TupleDesc tupdesc)
{
Form_pg_constraint con;
bool isnull;
Datum attr;
Datum expr;
con = (Form_pg_constraint) GETSTRUCT(contup);
attr = heap_getattr(contup, Anum_pg_constraint_conbin, tupdesc, &isnull);
if (isnull)
elog(ERROR, "null conbin for constraint %u", HeapTupleGetOid(contup));
expr = DirectFunctionCall2(pg_get_expr, attr,
ObjectIdGetDatum(con->conrelid));
Simplify and standardize conversions between TEXT datums and ordinary C strings. This patch introduces four support functions cstring_to_text, cstring_to_text_with_len, text_to_cstring, and text_to_cstring_buffer, and two macros CStringGetTextDatum and TextDatumGetCString. A number of existing macros that provided variants on these themes were removed. Most of the places that need to make such conversions now require just one function or macro call, in place of the multiple notational layers that used to be needed. There are no longer any direct calls of textout or textin, and we got most of the places that were using handmade conversions via memcpy (there may be a few still lurking, though). This commit doesn't make any serious effort to eliminate transient memory leaks caused by detoasting toasted text objects before they reach text_to_cstring. We changed PG_GETARG_TEXT_P to PG_GETARG_TEXT_PP in a few places where it was easy, but much more could be done. Brendan Jurd and Tom Lane
2008-03-25 23:42:46 +01:00
return TextDatumGetCString(expr);
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
}
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
/*
* Determine whether two check constraints are functionally equivalent
*
* The test we apply is to see whether they reverse-compile to the same
* source string. This insulates us from issues like whether attributes
* have the same physical column numbers in parent and child relations.
*/
static bool
constraints_equivalent(HeapTuple a, HeapTuple b, TupleDesc tupleDesc)
{
Form_pg_constraint acon = (Form_pg_constraint) GETSTRUCT(a);
Form_pg_constraint bcon = (Form_pg_constraint) GETSTRUCT(b);
if (acon->condeferrable != bcon->condeferrable ||
acon->condeferred != bcon->condeferred ||
strcmp(decompile_conbin(a, tupleDesc),
decompile_conbin(b, tupleDesc)) != 0)
return false;
else
return true;
}
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
/*
* Check columns in child table match up with columns in parent, and increment
* their attinhcount.
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
*
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
* Called by ATExecAddInherit
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
*
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
* Currently all parent columns must be found in child. Missing columns are an
* error. One day we might consider creating new columns like CREATE TABLE
* does. However, that is widely unpopular --- in the common use case of
* partitioned tables it's a foot-gun.
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
*
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
* The data type must match exactly. If the parent column is NOT NULL then
* the child must be as well. Defaults are not compared, however.
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
*/
static void
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
MergeAttributesIntoExisting(Relation child_rel, Relation parent_rel)
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
{
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
Relation attrrel;
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
AttrNumber parent_attno;
int parent_natts;
TupleDesc tupleDesc;
HeapTuple tuple;
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
attrrel = heap_open(AttributeRelationId, RowExclusiveLock);
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
tupleDesc = RelationGetDescr(parent_rel);
parent_natts = tupleDesc->natts;
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
for (parent_attno = 1; parent_attno <= parent_natts; parent_attno++)
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
{
Form_pg_attribute attribute = tupleDesc->attrs[parent_attno - 1];
char *attributeName = NameStr(attribute->attname);
/* Ignore dropped columns in the parent. */
if (attribute->attisdropped)
continue;
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
/* Find same column in child (matching on column name). */
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
tuple = SearchSysCacheCopyAttName(RelationGetRelid(child_rel),
attributeName);
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
if (HeapTupleIsValid(tuple))
{
Add check for matching column collations in ALTER TABLE ... INHERIT. 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.
2011-04-17 22:22:13 +02:00
/* Check they are same type, typmod, and collation */
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
Form_pg_attribute childatt = (Form_pg_attribute) GETSTRUCT(tuple);
if (attribute->atttypid != childatt->atttypid ||
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
attribute->atttypmod != childatt->atttypmod)
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("child table \"%s\" has different type for column \"%s\"",
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
RelationGetRelationName(child_rel),
attributeName)));
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
Add check for matching column collations in ALTER TABLE ... INHERIT. 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.
2011-04-17 22:22:13 +02:00
if (attribute->attcollation != childatt->attcollation)
ereport(ERROR,
(errcode(ERRCODE_COLLATION_MISMATCH),
errmsg("child table \"%s\" has different collation for column \"%s\"",
RelationGetRelationName(child_rel),
attributeName)));
/*
* Check child doesn't discard NOT NULL property. (Other
* constraints are checked elsewhere.)
*/
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
if (attribute->attnotnull && !childatt->attnotnull)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
errmsg("column \"%s\" in child table must be marked NOT NULL",
attributeName)));
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
/*
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
* OK, bump the child column's inheritance count. (If we fail
* later on, this change will just roll back.)
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
*/
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
childatt->attinhcount++;
simple_heap_update(attrrel, &tuple->t_self, tuple);
CatalogUpdateIndexes(attrrel, tuple);
heap_freetuple(tuple);
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
}
else
{
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
Message style improvements
2006-10-06 19:14:01 +02:00
errmsg("child table is missing column \"%s\"",
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
attributeName)));
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
}
}
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
heap_close(attrrel, RowExclusiveLock);
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
}
/*
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
* Check constraints in child table match up with constraints in parent,
* and increment their coninhcount.
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
*
Disallow merging ONLY constraints in children tables When creating a child table, or when attaching an existing table as child of another, we must not allow inheritable constraints to be merged with non-inheritable ones, because then grandchildren would not properly get the constraint. This would violate the grandparent's expectations. Bugs noted by Robert Haas. Author: Nikhil Sontakke
2012-01-16 23:19:42 +01:00
* Constraints that are marked ONLY in the parent are ignored.
*
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
* Called by ATExecAddInherit
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
*
* Currently all constraints in parent must be present in the child. One day we
Disallow merging ONLY constraints in children tables When creating a child table, or when attaching an existing table as child of another, we must not allow inheritable constraints to be merged with non-inheritable ones, because then grandchildren would not properly get the constraint. This would violate the grandparent's expectations. Bugs noted by Robert Haas. Author: Nikhil Sontakke
2012-01-16 23:19:42 +01:00
* may consider adding new constraints like CREATE TABLE does.
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
*
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
* XXX This is O(N^2) which may be an issue with tables with hundreds of
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
* constraints. As long as tables have more like 10 constraints it shouldn't be
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
* a problem though. Even 100 constraints ought not be the end of the world.
Disallow merging ONLY constraints in children tables When creating a child table, or when attaching an existing table as child of another, we must not allow inheritable constraints to be merged with non-inheritable ones, because then grandchildren would not properly get the constraint. This would violate the grandparent's expectations. Bugs noted by Robert Haas. Author: Nikhil Sontakke
2012-01-16 23:19:42 +01:00
*
* XXX See MergeWithExistingConstraint too if you change this code.
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
*/
static void
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
MergeConstraintsIntoExisting(Relation child_rel, Relation parent_rel)
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
{
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
Relation catalog_relation;
TupleDesc tuple_desc;
SysScanDesc parent_scan;
ScanKeyData parent_key;
HeapTuple parent_tuple;
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
catalog_relation = heap_open(ConstraintRelationId, RowExclusiveLock);
tuple_desc = RelationGetDescr(catalog_relation);
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
/* Outer loop scans through the parent's constraint definitions */
ScanKeyInit(&parent_key,
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
Anum_pg_constraint_conrelid,
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
BTEqualStrategyNumber, F_OIDEQ,
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
ObjectIdGetDatum(RelationGetRelid(parent_rel)));
parent_scan = systable_beginscan(catalog_relation, ConstraintRelidIndexId,
true, SnapshotNow, 1, &parent_key);
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
while (HeapTupleIsValid(parent_tuple = systable_getnext(parent_scan)))
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
{
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
Form_pg_constraint parent_con = (Form_pg_constraint) GETSTRUCT(parent_tuple);
SysScanDesc child_scan;
ScanKeyData child_key;
HeapTuple child_tuple;
bool found = false;
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
if (parent_con->contype != CONSTRAINT_CHECK)
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
continue;
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
Recast "ONLY" column CHECK constraints as NO INHERIT The original syntax wasn't universally loved, and it didn't allow its usage in CREATE TABLE, only ALTER TABLE. It now works everywhere, and it also allows using ALTER TABLE ONLY to add an uninherited CHECK constraint, per discussion. The pg_constraint column has accordingly been renamed connoinherit. This commit partly reverts some of the changes in 61d81bd28dbec65a6b144e0cd3d0bfe25913c3ac, particularly some pg_dump and psql bits, because now pg_get_constraintdef includes the necessary NO INHERIT within the constraint definition. Author: Nikhil Sontakke Some tweaks by me
2012-04-21 04:46:20 +02:00
/* if the parent's constraint is marked NO INHERIT, it's not inherited */
if (parent_con->connoinherit)
Disallow merging ONLY constraints in children tables When creating a child table, or when attaching an existing table as child of another, we must not allow inheritable constraints to be merged with non-inheritable ones, because then grandchildren would not properly get the constraint. This would violate the grandparent's expectations. Bugs noted by Robert Haas. Author: Nikhil Sontakke
2012-01-16 23:19:42 +01:00
continue;
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
/* Search for a child constraint matching this one */
ScanKeyInit(&child_key,
Anum_pg_constraint_conrelid,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(RelationGetRelid(child_rel)));
child_scan = systable_beginscan(catalog_relation, ConstraintRelidIndexId,
true, SnapshotNow, 1, &child_key);
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
while (HeapTupleIsValid(child_tuple = systable_getnext(child_scan)))
{
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
Form_pg_constraint child_con = (Form_pg_constraint) GETSTRUCT(child_tuple);
HeapTuple child_copy;
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
if (child_con->contype != CONSTRAINT_CHECK)
continue;
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
if (strcmp(NameStr(parent_con->conname),
NameStr(child_con->conname)) != 0)
continue;
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
if (!constraints_equivalent(parent_tuple, child_tuple, tuple_desc))
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("child table \"%s\" has different definition for check constraint \"%s\"",
RelationGetRelationName(child_rel),
NameStr(parent_con->conname))));
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
Recast "ONLY" column CHECK constraints as NO INHERIT The original syntax wasn't universally loved, and it didn't allow its usage in CREATE TABLE, only ALTER TABLE. It now works everywhere, and it also allows using ALTER TABLE ONLY to add an uninherited CHECK constraint, per discussion. The pg_constraint column has accordingly been renamed connoinherit. This commit partly reverts some of the changes in 61d81bd28dbec65a6b144e0cd3d0bfe25913c3ac, particularly some pg_dump and psql bits, because now pg_get_constraintdef includes the necessary NO INHERIT within the constraint definition. Author: Nikhil Sontakke Some tweaks by me
2012-04-21 04:46:20 +02:00
/* If the constraint is "no inherit" then cannot merge */
if (child_con->connoinherit)
Disallow merging ONLY constraints in children tables When creating a child table, or when attaching an existing table as child of another, we must not allow inheritable constraints to be merged with non-inheritable ones, because then grandchildren would not properly get the constraint. This would violate the grandparent's expectations. Bugs noted by Robert Haas. Author: Nikhil Sontakke
2012-01-16 23:19:42 +01:00
ereport(ERROR,
(errcode(ERRCODE_INVALID_OBJECT_DEFINITION),
errmsg("constraint \"%s\" conflicts with non-inherited constraint on child table \"%s\"",
NameStr(child_con->conname),
RelationGetRelationName(child_rel))));
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
/*
* OK, bump the child constraint's inheritance count. (If we fail
* later on, this change will just roll back.)
*/
child_copy = heap_copytuple(child_tuple);
child_con = (Form_pg_constraint) GETSTRUCT(child_copy);
child_con->coninhcount++;
simple_heap_update(catalog_relation, &child_copy->t_self, child_copy);
CatalogUpdateIndexes(catalog_relation, child_copy);
heap_freetuple(child_copy);
found = true;
break;
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
}
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
systable_endscan(child_scan);
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
if (!found)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
errmsg("child table is missing constraint \"%s\"",
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
NameStr(parent_con->conname))));
}
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
systable_endscan(parent_scan);
heap_close(catalog_relation, RowExclusiveLock);
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
}
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
/*
* ALTER TABLE NO INHERIT
*
* Drop a parent from the child's parents. This just adjusts the attinhcount
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
* and attislocal of the columns and removes the pg_inherit and pg_depend
* entries.
*
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
* If attinhcount goes to 0 then attislocal gets set to true. If it goes back
* up attislocal stays true, which means if a child is ever removed from a
* parent then its columns will never be automatically dropped which may
* surprise. But at least we'll never surprise by dropping columns someone
* isn't expecting to be dropped which would actually mean data loss.
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
*
* coninhcount and conislocal for inherited constraints are adjusted in
* exactly the same way.
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
*/
static void
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
ATExecDropInherit(Relation rel, RangeVar *parent, LOCKMODE lockmode)
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
{
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
Relation parent_rel;
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
Relation catalogRelation;
SysScanDesc scan;
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
ScanKeyData key[3];
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
HeapTuple inheritsTuple,
attributeTuple,
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
constraintTuple;
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
List *connames;
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
bool found = false;
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
/*
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* AccessShareLock on the parent is probably enough, seeing that DROP
* TABLE doesn't lock parent tables at all. We need some lock since we'll
* be inspecting the parent's schema.
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
*/
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
parent_rel = heap_openrv(parent, AccessShareLock);
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
/*
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* We don't bother to check ownership of the parent table --- ownership of
* the child is presumed enough rights.
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
*/
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
/*
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* Find and destroy the pg_inherits entry linking the two, or error out if
* there is none.
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
*/
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
catalogRelation = heap_open(InheritsRelationId, RowExclusiveLock);
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
ScanKeyInit(&key[0],
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
Anum_pg_inherits_inhrelid,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(RelationGetRelid(rel)));
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
scan = systable_beginscan(catalogRelation, InheritsRelidSeqnoIndexId,
true, SnapshotNow, 1, key);
while (HeapTupleIsValid(inheritsTuple = systable_getnext(scan)))
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
{
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
Oid inhparent;
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
inhparent = ((Form_pg_inherits) GETSTRUCT(inheritsTuple))->inhparent;
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
if (inhparent == RelationGetRelid(parent_rel))
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
{
simple_heap_delete(catalogRelation, &inheritsTuple->t_self);
found = true;
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
break;
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
}
}
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
systable_endscan(scan);
heap_close(catalogRelation, RowExclusiveLock);
if (!found)
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_TABLE),
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
errmsg("relation \"%s\" is not a parent of relation \"%s\"",
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
RelationGetRelationName(parent_rel),
RelationGetRelationName(rel))));
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
/*
* Search through child columns looking for ones matching parent rel
*/
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
catalogRelation = heap_open(AttributeRelationId, RowExclusiveLock);
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
ScanKeyInit(&key[0],
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
Anum_pg_attribute_attrelid,
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
BTEqualStrategyNumber, F_OIDEQ,
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
ObjectIdGetDatum(RelationGetRelid(rel)));
scan = systable_beginscan(catalogRelation, AttributeRelidNumIndexId,
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
true, SnapshotNow, 1, key);
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
while (HeapTupleIsValid(attributeTuple = systable_getnext(scan)))
{
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
Form_pg_attribute att = (Form_pg_attribute) GETSTRUCT(attributeTuple);
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
/* Ignore if dropped or not inherited */
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
if (att->attisdropped)
continue;
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
if (att->attinhcount <= 0)
continue;
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
if (SearchSysCacheExistsAttName(RelationGetRelid(parent_rel),
NameStr(att->attname)))
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
{
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
/* Decrement inhcount and possibly set islocal to true */
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
HeapTuple copyTuple = heap_copytuple(attributeTuple);
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
Form_pg_attribute copy_att = (Form_pg_attribute) GETSTRUCT(copyTuple);
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
copy_att->attinhcount--;
if (copy_att->attinhcount == 0)
copy_att->attislocal = true;
simple_heap_update(catalogRelation, &copyTuple->t_self, copyTuple);
CatalogUpdateIndexes(catalogRelation, copyTuple);
heap_freetuple(copyTuple);
}
}
systable_endscan(scan);
heap_close(catalogRelation, RowExclusiveLock);
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
/*
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* Likewise, find inherited check constraints and disinherit them. To do
* this, we first need a list of the names of the parent's check
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
* constraints. (We cheat a bit by only checking for name matches,
* assuming that the expressions will match.)
*/
catalogRelation = heap_open(ConstraintRelationId, RowExclusiveLock);
ScanKeyInit(&key[0],
Anum_pg_constraint_conrelid,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(RelationGetRelid(parent_rel)));
scan = systable_beginscan(catalogRelation, ConstraintRelidIndexId,
true, SnapshotNow, 1, key);
connames = NIL;
while (HeapTupleIsValid(constraintTuple = systable_getnext(scan)))
{
Form_pg_constraint con = (Form_pg_constraint) GETSTRUCT(constraintTuple);
if (con->contype == CONSTRAINT_CHECK)
connames = lappend(connames, pstrdup(NameStr(con->conname)));
}
systable_endscan(scan);
/* Now scan the child's constraints */
ScanKeyInit(&key[0],
Anum_pg_constraint_conrelid,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(RelationGetRelid(rel)));
scan = systable_beginscan(catalogRelation, ConstraintRelidIndexId,
true, SnapshotNow, 1, key);
while (HeapTupleIsValid(constraintTuple = systable_getnext(scan)))
{
Form_pg_constraint con = (Form_pg_constraint) GETSTRUCT(constraintTuple);
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
bool match;
ListCell *lc;
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
if (con->contype != CONSTRAINT_CHECK)
continue;
match = false;
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
foreach(lc, connames)
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
{
if (strcmp(NameStr(con->conname), (char *) lfirst(lc)) == 0)
{
match = true;
break;
}
}
if (match)
{
/* Decrement inhcount and possibly set islocal to true */
HeapTuple copyTuple = heap_copytuple(constraintTuple);
Form_pg_constraint copy_con = (Form_pg_constraint) GETSTRUCT(copyTuple);
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
if (copy_con->coninhcount <= 0) /* shouldn't happen */
elog(ERROR, "relation %u has non-inherited constraint \"%s\"",
RelationGetRelid(rel), NameStr(copy_con->conname));
copy_con->coninhcount--;
if (copy_con->coninhcount == 0)
copy_con->conislocal = true;
simple_heap_update(catalogRelation, &copyTuple->t_self, copyTuple);
CatalogUpdateIndexes(catalogRelation, copyTuple);
heap_freetuple(copyTuple);
}
}
systable_endscan(scan);
heap_close(catalogRelation, RowExclusiveLock);
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
drop_parent_dependency(RelationGetRelid(rel),
RelationRelationId,
RelationGetRelid(parent_rel));
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
/*
pgindent run for release 9.3 This is the first run of the Perl-based pgindent script. Also update pgindent instructions.
2013-05-29 22:58:43 +02:00
* Post alter hook of this inherits. Since object_access_hook doesn't take
* multiple object identifiers, we relay oid of parent relation using
* auxiliary_id argument.
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
*/
InvokeObjectPostAlterHookArg(InheritsRelationId,
RelationGetRelid(rel), 0,
RelationGetRelid(parent_rel), false);
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
/* keep our lock on the parent relation until commit */
heap_close(parent_rel, NoLock);
}
/*
* Drop the dependency created by StoreCatalogInheritance1 (CREATE TABLE
* INHERITS/ALTER TABLE INHERIT -- refclassid will be RelationRelationId) or
* heap_create_with_catalog (CREATE TABLE OF/ALTER TABLE OF -- refclassid will
Pgindent run before 9.1 beta2.
2011-06-09 20:32:50 +02:00
* be TypeRelationId). There's no convenient way to do this, so go trawling
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
* through pg_depend.
*/
static void
drop_parent_dependency(Oid relid, Oid refclassid, Oid refobjid)
{
Relation catalogRelation;
SysScanDesc scan;
ScanKeyData key[3];
HeapTuple depTuple;
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
catalogRelation = heap_open(DependRelationId, RowExclusiveLock);
ScanKeyInit(&key[0],
Anum_pg_depend_classid,
BTEqualStrategyNumber, F_OIDEQ,
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
ObjectIdGetDatum(RelationRelationId));
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
ScanKeyInit(&key[1],
Anum_pg_depend_objid,
BTEqualStrategyNumber, F_OIDEQ,
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
ObjectIdGetDatum(relid));
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
ScanKeyInit(&key[2],
Anum_pg_depend_objsubid,
BTEqualStrategyNumber, F_INT4EQ,
Int32GetDatum(0));
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
scan = systable_beginscan(catalogRelation, DependDependerIndexId, true,
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
SnapshotNow, 3, key);
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
while (HeapTupleIsValid(depTuple = systable_getnext(scan)))
{
Form_pg_depend dep = (Form_pg_depend) GETSTRUCT(depTuple);
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
if (dep->refclassid == refclassid &&
dep->refobjid == refobjid &&
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
dep->refobjsubid == 0 &&
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
dep->deptype == DEPENDENCY_NORMAL)
simple_heap_delete(catalogRelation, &depTuple->t_self);
}
Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep 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.
2006-07-02 07:17:26 +02:00
systable_endscan(scan);
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
heap_close(catalogRelation, RowExclusiveLock);
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
}
Code and docs review for ALTER TABLE INHERIT/NO INHERIT patch.
2006-10-13 23:43:19 +02:00
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
/*
* ALTER TABLE OF
*
* Attach a table to a composite type, as though it had been created with CREATE
* TABLE OF. All attname, atttypid, atttypmod and attcollation must match. The
* subject table must not have inheritance parents. These restrictions ensure
* that you cannot create a configuration impossible with CREATE TABLE OF alone.
*/
static void
ATExecAddOf(Relation rel, const TypeName *ofTypename, LOCKMODE lockmode)
{
Oid relid = RelationGetRelid(rel);
Type typetuple;
Oid typeid;
Relation inheritsRelation,
relationRelation;
SysScanDesc scan;
ScanKeyData key;
AttrNumber table_attno,
type_attno;
TupleDesc typeTupleDesc,
tableTupleDesc;
ObjectAddress tableobj,
typeobj;
HeapTuple classtuple;
/* Validate the type. */
typetuple = typenameType(NULL, ofTypename, NULL);
check_of_type(typetuple);
typeid = HeapTupleGetOid(typetuple);
/* Fail if the table has any inheritance parents. */
inheritsRelation = heap_open(InheritsRelationId, AccessShareLock);
ScanKeyInit(&key,
Anum_pg_inherits_inhrelid,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(relid));
scan = systable_beginscan(inheritsRelation, InheritsRelidSeqnoIndexId,
true, SnapshotNow, 1, &key);
if (HeapTupleIsValid(systable_getnext(scan)))
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("typed tables cannot inherit")));
systable_endscan(scan);
heap_close(inheritsRelation, AccessShareLock);
/*
* Check the tuple descriptors for compatibility. Unlike inheritance, we
* require that the order also match. However, attnotnull need not match.
* Also unlike inheritance, we do not require matching relhasoids.
*/
typeTupleDesc = lookup_rowtype_tupdesc(typeid, -1);
tableTupleDesc = RelationGetDescr(rel);
table_attno = 1;
for (type_attno = 1; type_attno <= typeTupleDesc->natts; type_attno++)
{
Form_pg_attribute type_attr,
table_attr;
const char *type_attname,
*table_attname;
/* Get the next non-dropped type attribute. */
type_attr = typeTupleDesc->attrs[type_attno - 1];
if (type_attr->attisdropped)
continue;
type_attname = NameStr(type_attr->attname);
/* Get the next non-dropped table attribute. */
do
{
if (table_attno > tableTupleDesc->natts)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("table is missing column \"%s\"",
type_attname)));
table_attr = tableTupleDesc->attrs[table_attno++ - 1];
} while (table_attr->attisdropped);
table_attname = NameStr(table_attr->attname);
/* Compare name. */
if (strncmp(table_attname, type_attname, NAMEDATALEN) != 0)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
Pgindent run before 9.1 beta2.
2011-06-09 20:32:50 +02:00
errmsg("table has column \"%s\" where type requires \"%s\"",
table_attname, type_attname)));
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
/* Compare type. */
if (table_attr->atttypid != type_attr->atttypid ||
table_attr->atttypmod != type_attr->atttypmod ||
table_attr->attcollation != type_attr->attcollation)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
Pgindent run before 9.1 beta2.
2011-06-09 20:32:50 +02:00
errmsg("table \"%s\" has different type for column \"%s\"",
RelationGetRelationName(rel), type_attname)));
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
}
DecrTupleDescRefCount(typeTupleDesc);
/* Any remaining columns at the end of the table had better be dropped. */
for (; table_attno <= tableTupleDesc->natts; table_attno++)
{
Form_pg_attribute table_attr = tableTupleDesc->attrs[table_attno - 1];
Pgindent run before 9.1 beta2.
2011-06-09 20:32:50 +02:00
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
if (!table_attr->attisdropped)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("table has extra column \"%s\"",
NameStr(table_attr->attname))));
}
/* If the table was already typed, drop the existing dependency. */
if (rel->rd_rel->reloftype)
drop_parent_dependency(relid, TypeRelationId, rel->rd_rel->reloftype);
/* Record a dependency on the new type. */
tableobj.classId = RelationRelationId;
tableobj.objectId = relid;
tableobj.objectSubId = 0;
typeobj.classId = TypeRelationId;
typeobj.objectId = typeid;
typeobj.objectSubId = 0;
recordDependencyOn(&tableobj, &typeobj, DEPENDENCY_NORMAL);
/* Update pg_class.reloftype */
relationRelation = heap_open(RelationRelationId, RowExclusiveLock);
classtuple = SearchSysCacheCopy1(RELOID, ObjectIdGetDatum(relid));
if (!HeapTupleIsValid(classtuple))
elog(ERROR, "cache lookup failed for relation %u", relid);
((Form_pg_class) GETSTRUCT(classtuple))->reloftype = typeid;
simple_heap_update(relationRelation, &classtuple->t_self, classtuple);
CatalogUpdateIndexes(relationRelation, classtuple);
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
InvokeObjectPostAlterHook(RelationRelationId, relid, 0);
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
heap_freetuple(classtuple);
heap_close(relationRelation, RowExclusiveLock);
ReleaseSysCache(typetuple);
}
/*
* ALTER TABLE NOT OF
*
Pgindent run before 9.1 beta2.
2011-06-09 20:32:50 +02:00
* Detach a typed table from its originating type. Just clear reloftype and
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
* remove the dependency.
*/
static void
ATExecDropOf(Relation rel, LOCKMODE lockmode)
{
Oid relid = RelationGetRelid(rel);
Relation relationRelation;
HeapTuple tuple;
if (!OidIsValid(rel->rd_rel->reloftype))
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("\"%s\" is not a typed table",
RelationGetRelationName(rel))));
/*
Pgindent run before 9.1 beta2.
2011-06-09 20:32:50 +02:00
* We don't bother to check ownership of the type --- ownership of the
* table is presumed enough rights. No lock required on the type, either.
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
*/
drop_parent_dependency(relid, TypeRelationId, rel->rd_rel->reloftype);
/* Clear pg_class.reloftype */
relationRelation = heap_open(RelationRelationId, RowExclusiveLock);
tuple = SearchSysCacheCopy1(RELOID, ObjectIdGetDatum(relid));
if (!HeapTupleIsValid(tuple))
elog(ERROR, "cache lookup failed for relation %u", relid);
((Form_pg_class) GETSTRUCT(tuple))->reloftype = InvalidOid;
simple_heap_update(relationRelation, &tuple->t_self, tuple);
CatalogUpdateIndexes(relationRelation, tuple);
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
InvokeObjectPostAlterHook(RelationRelationId, relid, 0);
Allow ALTER TABLE name {OF type | NOT OF}. 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
2011-04-21 03:35:15 +02:00
heap_freetuple(tuple);
heap_close(relationRelation, RowExclusiveLock);
ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) 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
2006-07-02 03:58:36 +02:00
}
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
/*
* ALTER FOREIGN TABLE <name> OPTIONS (...)
*/
static void
ATExecGenericOptions(Relation rel, List *options)
{
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
Relation ftrel;
ForeignServer *server;
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
ForeignDataWrapper *fdw;
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
HeapTuple tuple;
bool isnull;
Datum repl_val[Natts_pg_foreign_table];
bool repl_null[Natts_pg_foreign_table];
bool repl_repl[Natts_pg_foreign_table];
Datum datum;
Form_pg_foreign_table tableform;
if (options == NIL)
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
return;
ftrel = heap_open(ForeignTableRelationId, RowExclusiveLock);
tuple = SearchSysCacheCopy1(FOREIGNTABLEREL, rel->rd_id);
if (!HeapTupleIsValid(tuple))
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_OBJECT),
errmsg("foreign table \"%s\" does not exist",
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
RelationGetRelationName(rel))));
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
tableform = (Form_pg_foreign_table) GETSTRUCT(tuple);
server = GetForeignServer(tableform->ftserver);
fdw = GetForeignDataWrapper(server->fdwid);
memset(repl_val, 0, sizeof(repl_val));
memset(repl_null, false, sizeof(repl_null));
memset(repl_repl, false, sizeof(repl_repl));
/* Extract the current options */
datum = SysCacheGetAttr(FOREIGNTABLEREL,
tuple,
Anum_pg_foreign_table_ftoptions,
&isnull);
if (isnull)
datum = PointerGetDatum(NULL);
/* Transform the options */
datum = transformGenericOptions(ForeignTableRelationId,
datum,
options,
fdw->fdwvalidator);
if (PointerIsValid(DatumGetPointer(datum)))
repl_val[Anum_pg_foreign_table_ftoptions - 1] = datum;
else
repl_null[Anum_pg_foreign_table_ftoptions - 1] = true;
repl_repl[Anum_pg_foreign_table_ftoptions - 1] = true;
/* Everything looks good - update the tuple */
tuple = heap_modify_tuple(tuple, RelationGetDescr(ftrel),
repl_val, repl_null, repl_repl);
simple_heap_update(ftrel, &tuple->t_self, tuple);
CatalogUpdateIndexes(ftrel, tuple);
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
InvokeObjectPostAlterHook(ForeignTableRelationId,
RelationGetRelid(rel), 0);
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
heap_close(ftrel, RowExclusiveLock);
heap_freetuple(tuple);
}
Improve behavior of concurrent ALTER <relation> .. SET SCHEMA. If the referrent of a name changes while we're waiting for the lock, we must recheck permissons. We also now check the relkind before locking, since it's easy to do that long the way. Patch by me; review by Noah Misch.
2011-12-16 01:02:58 +01:00
/*
* Execute ALTER TABLE SET SCHEMA
*/
Adjust many backend functions to return OID rather than void. Extracted from a larger patch by Dimitri Fontaine. It is hoped that this will provide infrastructure for enriching the new event trigger functionality, but it seems possibly useful for other purposes as well.
2012-12-24 00:25:03 +01:00
Oid
Improve behavior of concurrent ALTER TABLE, and do some refactoring. ALTER TABLE (and ALTER VIEW, ALTER SEQUENCE, etc.) now use a RangeVarGetRelid callback to check permissions before acquiring a table lock. We also now use the same callback for all forms of ALTER TABLE, rather than having separate, almost-identical callbacks for ALTER TABLE .. SET SCHEMA and ALTER TABLE .. RENAME, and no callback at all for everything else. I went ahead and changed the code so that no form of ALTER TABLE works on foreign tables; you must use ALTER FOREIGN TABLE instead. In 9.1, it was possible to use ALTER TABLE .. SET SCHEMA or ALTER TABLE .. RENAME on a foreign table, but not any other form of ALTER TABLE, which did not seem terribly useful or consistent. Patch by me; review by Noah Misch.
2012-01-07 04:42:26 +01:00
AlterTableNamespace(AlterObjectSchemaStmt *stmt)
Improve behavior of concurrent ALTER <relation> .. SET SCHEMA. If the referrent of a name changes while we're waiting for the lock, we must recheck permissons. We also now check the relkind before locking, since it's easy to do that long the way. Patch by me; review by Noah Misch.
2011-12-16 01:02:58 +01:00
{
Relation rel;
Oid relid;
Oid oldNspOid;
Oid nspOid;
Prevent adding relations to a concurrently dropped schema. In the previous coding, it was possible for a relation to be created via CREATE TABLE, CREATE VIEW, CREATE SEQUENCE, CREATE FOREIGN TABLE, etc. in a schema while that schema was meanwhile being concurrently dropped. This led to a pg_class entry with an invalid relnamespace value. The same problem could occur if a relation was moved using ALTER .. SET SCHEMA while the target schema was being concurrently dropped. This patch prevents both of those scenarios by locking the schema to which the relation is being added using AccessShareLock, which conflicts with the AccessExclusiveLock taken by DROP. As a desirable side effect, this also prevents the use of CREATE OR REPLACE VIEW to queue for an AccessExclusiveLock on a relation on which you have no rights: that will now fail immediately with a permissions error, before trying to obtain a lock. We need similar protection for all other object types, but as everything other than relations uses a slightly different set of code paths, I'm leaving that for a separate commit. Original complaint (as far as I could find) about CREATE by Nikhil Sontakke; risk for ALTER .. SET SCHEMA pointed out by Tom Lane; further details by Dan Farina; patch by me; review by Hitoshi Harada.
2012-01-16 15:34:21 +01:00
RangeVar *newrv;
Fix ALTER EXTENSION / SET SCHEMA In its original conception, it was leaving some objects into the old schema, but without their proper pg_depend entries; this meant that the old schema could be dropped, causing future pg_dump calls to fail on the affected database. This was originally reported by Jeff Frost as #6704; there have been other complaints elsewhere that can probably be traced to this bug. To fix, be more consistent about altering a table's subsidiary objects along the table itself; this requires some restructuring in how tables are relocated when altering an extension -- hence the new AlterTableNamespaceInternal routine which encapsulates it for both the ALTER TABLE and the ALTER EXTENSION cases. There was another bug lurking here, which was unmasked after fixing the previous one: certain objects would be reached twice via the dependency graph, and the second attempt to move them would cause the entire operation to fail. Per discussion, it seems the best fix for this is to do more careful tracking of objects already moved: we now maintain a list of moved objects, to avoid attempting to do it twice for the same object. Authors: Alvaro Herrera, Dimitri Fontaine Reviewed by Tom Lane
2012-10-31 14:52:55 +01:00
ObjectAddresses *objsMoved;
Improve behavior of concurrent ALTER <relation> .. SET SCHEMA. If the referrent of a name changes while we're waiting for the lock, we must recheck permissons. We also now check the relkind before locking, since it's easy to do that long the way. Patch by me; review by Noah Misch.
2011-12-16 01:02:58 +01:00
Improve behavior of concurrent ALTER TABLE, and do some refactoring. ALTER TABLE (and ALTER VIEW, ALTER SEQUENCE, etc.) now use a RangeVarGetRelid callback to check permissions before acquiring a table lock. We also now use the same callback for all forms of ALTER TABLE, rather than having separate, almost-identical callbacks for ALTER TABLE .. SET SCHEMA and ALTER TABLE .. RENAME, and no callback at all for everything else. I went ahead and changed the code so that no form of ALTER TABLE works on foreign tables; you must use ALTER FOREIGN TABLE instead. In 9.1, it was possible to use ALTER TABLE .. SET SCHEMA or ALTER TABLE .. RENAME on a foreign table, but not any other form of ALTER TABLE, which did not seem terribly useful or consistent. Patch by me; review by Noah Misch.
2012-01-07 04:42:26 +01:00
relid = RangeVarGetRelidExtended(stmt->relation, AccessExclusiveLock,
ALTER <thing> [IF EXISTS] ... allows silent DDL if required, e.g. ALTER FOREIGN TABLE IF EXISTS foo RENAME TO bar Pavel Stehule
2012-01-24 00:25:04 +01:00
stmt->missing_ok, false,
Improve behavior of concurrent ALTER TABLE, and do some refactoring. ALTER TABLE (and ALTER VIEW, ALTER SEQUENCE, etc.) now use a RangeVarGetRelid callback to check permissions before acquiring a table lock. We also now use the same callback for all forms of ALTER TABLE, rather than having separate, almost-identical callbacks for ALTER TABLE .. SET SCHEMA and ALTER TABLE .. RENAME, and no callback at all for everything else. I went ahead and changed the code so that no form of ALTER TABLE works on foreign tables; you must use ALTER FOREIGN TABLE instead. In 9.1, it was possible to use ALTER TABLE .. SET SCHEMA or ALTER TABLE .. RENAME on a foreign table, but not any other form of ALTER TABLE, which did not seem terribly useful or consistent. Patch by me; review by Noah Misch.
2012-01-07 04:42:26 +01:00
RangeVarCallbackForAlterRelation,
(void *) stmt);
ALTER <thing> [IF EXISTS] ... allows silent DDL if required, e.g. ALTER FOREIGN TABLE IF EXISTS foo RENAME TO bar Pavel Stehule
2012-01-24 00:25:04 +01:00
if (!OidIsValid(relid))
{
ereport(NOTICE,
(errmsg("relation \"%s\" does not exist, skipping",
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
stmt->relation->relname)));
Adjust many backend functions to return OID rather than void. Extracted from a larger patch by Dimitri Fontaine. It is hoped that this will provide infrastructure for enriching the new event trigger functionality, but it seems possibly useful for other purposes as well.
2012-12-24 00:25:03 +01:00
return InvalidOid;
ALTER <thing> [IF EXISTS] ... allows silent DDL if required, e.g. ALTER FOREIGN TABLE IF EXISTS foo RENAME TO bar Pavel Stehule
2012-01-24 00:25:04 +01:00
}
Improve behavior of concurrent ALTER <relation> .. SET SCHEMA. If the referrent of a name changes while we're waiting for the lock, we must recheck permissons. We also now check the relkind before locking, since it's easy to do that long the way. Patch by me; review by Noah Misch.
2011-12-16 01:02:58 +01:00
rel = relation_open(relid, NoLock);
oldNspOid = RelationGetNamespace(rel);
/* If it's an owned sequence, disallow moving it by itself. */
if (rel->rd_rel->relkind == RELKIND_SEQUENCE)
{
Oid tableId;
int32 colId;
if (sequenceIsOwned(relid, &tableId, &colId))
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
errmsg("cannot move an owned sequence into another schema"),
errdetail("Sequence \"%s\" is linked to table \"%s\".",
RelationGetRelationName(rel),
get_rel_name(tableId))));
Fix all known problems with pg_dump's handling of serial sequences 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.
2006-08-21 02:57:26 +02:00
}
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
Prevent adding relations to a concurrently dropped schema. In the previous coding, it was possible for a relation to be created via CREATE TABLE, CREATE VIEW, CREATE SEQUENCE, CREATE FOREIGN TABLE, etc. in a schema while that schema was meanwhile being concurrently dropped. This led to a pg_class entry with an invalid relnamespace value. The same problem could occur if a relation was moved using ALTER .. SET SCHEMA while the target schema was being concurrently dropped. This patch prevents both of those scenarios by locking the schema to which the relation is being added using AccessShareLock, which conflicts with the AccessExclusiveLock taken by DROP. As a desirable side effect, this also prevents the use of CREATE OR REPLACE VIEW to queue for an AccessExclusiveLock on a relation on which you have no rights: that will now fail immediately with a permissions error, before trying to obtain a lock. We need similar protection for all other object types, but as everything other than relations uses a slightly different set of code paths, I'm leaving that for a separate commit. Original complaint (as far as I could find) about CREATE by Nikhil Sontakke; risk for ALTER .. SET SCHEMA pointed out by Tom Lane; further details by Dan Farina; patch by me; review by Hitoshi Harada.
2012-01-16 15:34:21 +01:00
/* Get and lock schema OID and check its permissions. */
newrv = makeRangeVar(stmt->newschema, RelationGetRelationName(rel), -1);
nspOid = RangeVarGetAndCheckCreationNamespace(newrv, NoLock, NULL);
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
Centralize some ALTER <whatever> .. SET SCHEMA checks. Any flavor of ALTER <whatever> .. SET SCHEMA fails if (1) the object is already in the new schema, (2) either the old or new schema is a temp schema, or (3) either the old or new schema is the TOAST schema. Extraced from a patch by Dimitri Fontaine, with additional hacking by me.
2010-11-23 01:46:15 +01:00
/* common checks on switching namespaces */
CheckSetNamespace(oldNspOid, nspOid, RelationRelationId, relid);
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
Fix ALTER EXTENSION / SET SCHEMA In its original conception, it was leaving some objects into the old schema, but without their proper pg_depend entries; this meant that the old schema could be dropped, causing future pg_dump calls to fail on the affected database. This was originally reported by Jeff Frost as #6704; there have been other complaints elsewhere that can probably be traced to this bug. To fix, be more consistent about altering a table's subsidiary objects along the table itself; this requires some restructuring in how tables are relocated when altering an extension -- hence the new AlterTableNamespaceInternal routine which encapsulates it for both the ALTER TABLE and the ALTER EXTENSION cases. There was another bug lurking here, which was unmasked after fixing the previous one: certain objects would be reached twice via the dependency graph, and the second attempt to move them would cause the entire operation to fail. Per discussion, it seems the best fix for this is to do more careful tracking of objects already moved: we now maintain a list of moved objects, to avoid attempting to do it twice for the same object. Authors: Alvaro Herrera, Dimitri Fontaine Reviewed by Tom Lane
2012-10-31 14:52:55 +01:00
objsMoved = new_object_addresses();
AlterTableNamespaceInternal(rel, oldNspOid, nspOid, objsMoved);
free_object_addresses(objsMoved);
/* close rel, but keep lock until commit */
relation_close(rel, NoLock);
Adjust many backend functions to return OID rather than void. Extracted from a larger patch by Dimitri Fontaine. It is hoped that this will provide infrastructure for enriching the new event trigger functionality, but it seems possibly useful for other purposes as well.
2012-12-24 00:25:03 +01:00
return relid;
Fix ALTER EXTENSION / SET SCHEMA In its original conception, it was leaving some objects into the old schema, but without their proper pg_depend entries; this meant that the old schema could be dropped, causing future pg_dump calls to fail on the affected database. This was originally reported by Jeff Frost as #6704; there have been other complaints elsewhere that can probably be traced to this bug. To fix, be more consistent about altering a table's subsidiary objects along the table itself; this requires some restructuring in how tables are relocated when altering an extension -- hence the new AlterTableNamespaceInternal routine which encapsulates it for both the ALTER TABLE and the ALTER EXTENSION cases. There was another bug lurking here, which was unmasked after fixing the previous one: certain objects would be reached twice via the dependency graph, and the second attempt to move them would cause the entire operation to fail. Per discussion, it seems the best fix for this is to do more careful tracking of objects already moved: we now maintain a list of moved objects, to avoid attempting to do it twice for the same object. Authors: Alvaro Herrera, Dimitri Fontaine Reviewed by Tom Lane
2012-10-31 14:52:55 +01:00
}
/*
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
* The guts of relocating a table or materialized view to another namespace:
* besides moving the relation itself, its dependent objects are relocated to
* the new schema.
Fix ALTER EXTENSION / SET SCHEMA In its original conception, it was leaving some objects into the old schema, but without their proper pg_depend entries; this meant that the old schema could be dropped, causing future pg_dump calls to fail on the affected database. This was originally reported by Jeff Frost as #6704; there have been other complaints elsewhere that can probably be traced to this bug. To fix, be more consistent about altering a table's subsidiary objects along the table itself; this requires some restructuring in how tables are relocated when altering an extension -- hence the new AlterTableNamespaceInternal routine which encapsulates it for both the ALTER TABLE and the ALTER EXTENSION cases. There was another bug lurking here, which was unmasked after fixing the previous one: certain objects would be reached twice via the dependency graph, and the second attempt to move them would cause the entire operation to fail. Per discussion, it seems the best fix for this is to do more careful tracking of objects already moved: we now maintain a list of moved objects, to avoid attempting to do it twice for the same object. Authors: Alvaro Herrera, Dimitri Fontaine Reviewed by Tom Lane
2012-10-31 14:52:55 +01:00
*/
void
AlterTableNamespaceInternal(Relation rel, Oid oldNspOid, Oid nspOid,
ObjectAddresses *objsMoved)
{
Relation classRel;
Assert(objsMoved != NULL);
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
/* OK, modify the pg_class row and pg_depend entry */
classRel = heap_open(RelationRelationId, RowExclusiveLock);
Fix ALTER EXTENSION / SET SCHEMA In its original conception, it was leaving some objects into the old schema, but without their proper pg_depend entries; this meant that the old schema could be dropped, causing future pg_dump calls to fail on the affected database. This was originally reported by Jeff Frost as #6704; there have been other complaints elsewhere that can probably be traced to this bug. To fix, be more consistent about altering a table's subsidiary objects along the table itself; this requires some restructuring in how tables are relocated when altering an extension -- hence the new AlterTableNamespaceInternal routine which encapsulates it for both the ALTER TABLE and the ALTER EXTENSION cases. There was another bug lurking here, which was unmasked after fixing the previous one: certain objects would be reached twice via the dependency graph, and the second attempt to move them would cause the entire operation to fail. Per discussion, it seems the best fix for this is to do more careful tracking of objects already moved: we now maintain a list of moved objects, to avoid attempting to do it twice for the same object. Authors: Alvaro Herrera, Dimitri Fontaine Reviewed by Tom Lane
2012-10-31 14:52:55 +01:00
AlterRelationNamespaceInternal(classRel, RelationGetRelid(rel), oldNspOid,
nspOid, true, objsMoved);
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
Message style and spelling improvements
2011-06-21 23:33:20 +02:00
/* Fix the table's row type too */
Fix ALTER EXTENSION / SET SCHEMA In its original conception, it was leaving some objects into the old schema, but without their proper pg_depend entries; this meant that the old schema could be dropped, causing future pg_dump calls to fail on the affected database. This was originally reported by Jeff Frost as #6704; there have been other complaints elsewhere that can probably be traced to this bug. To fix, be more consistent about altering a table's subsidiary objects along the table itself; this requires some restructuring in how tables are relocated when altering an extension -- hence the new AlterTableNamespaceInternal routine which encapsulates it for both the ALTER TABLE and the ALTER EXTENSION cases. There was another bug lurking here, which was unmasked after fixing the previous one: certain objects would be reached twice via the dependency graph, and the second attempt to move them would cause the entire operation to fail. Per discussion, it seems the best fix for this is to do more careful tracking of objects already moved: we now maintain a list of moved objects, to avoid attempting to do it twice for the same object. Authors: Alvaro Herrera, Dimitri Fontaine Reviewed by Tom Lane
2012-10-31 14:52:55 +01:00
AlterTypeNamespaceInternal(rel->rd_rel->reltype,
nspOid, false, false, objsMoved);
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
/* Fix other dependent stuff */
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
if (rel->rd_rel->relkind == RELKIND_RELATION ||
rel->rd_rel->relkind == RELKIND_MATVIEW)
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
{
Fix ALTER EXTENSION / SET SCHEMA In its original conception, it was leaving some objects into the old schema, but without their proper pg_depend entries; this meant that the old schema could be dropped, causing future pg_dump calls to fail on the affected database. This was originally reported by Jeff Frost as #6704; there have been other complaints elsewhere that can probably be traced to this bug. To fix, be more consistent about altering a table's subsidiary objects along the table itself; this requires some restructuring in how tables are relocated when altering an extension -- hence the new AlterTableNamespaceInternal routine which encapsulates it for both the ALTER TABLE and the ALTER EXTENSION cases. There was another bug lurking here, which was unmasked after fixing the previous one: certain objects would be reached twice via the dependency graph, and the second attempt to move them would cause the entire operation to fail. Per discussion, it seems the best fix for this is to do more careful tracking of objects already moved: we now maintain a list of moved objects, to avoid attempting to do it twice for the same object. Authors: Alvaro Herrera, Dimitri Fontaine Reviewed by Tom Lane
2012-10-31 14:52:55 +01:00
AlterIndexNamespaces(classRel, rel, oldNspOid, nspOid, objsMoved);
AlterSeqNamespaces(classRel, rel, oldNspOid, nspOid,
objsMoved, AccessExclusiveLock);
AlterConstraintNamespaces(RelationGetRelid(rel), oldNspOid, nspOid,
false, objsMoved);
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
}
heap_close(classRel, RowExclusiveLock);
}
/*
* The guts of relocating a relation to another namespace: fix the pg_class
* entry, and the pg_depend entry if any. Caller must already have
* opened and write-locked pg_class.
*/
void
AlterRelationNamespaceInternal(Relation classRel, Oid relOid,
Oid oldNspOid, Oid newNspOid,
pgindent run for release 9.3 This is the first run of the Perl-based pgindent script. Also update pgindent instructions.
2013-05-29 22:58:43 +02:00
bool hasDependEntry, ObjectAddresses *objsMoved)
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
{
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
HeapTuple classTup;
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
Form_pg_class classForm;
pgindent run for release 9.3 This is the first run of the Perl-based pgindent script. Also update pgindent instructions.
2013-05-29 22:58:43 +02:00
ObjectAddress thisobj;
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
Wrap calls to SearchSysCache and related functions using macros. The purpose of this change is to eliminate the need for every caller of SearchSysCache, SearchSysCacheCopy, SearchSysCacheExists, GetSysCacheOid, and SearchSysCacheList to know the maximum number of allowable keys for a syscache entry (currently 4). This will make it far easier to increase the maximum number of keys in a future release should we choose to do so, and it makes the code shorter, too. Design and review by Tom Lane.
2010-02-14 19:42:19 +01:00
classTup = SearchSysCacheCopy1(RELOID, ObjectIdGetDatum(relOid));
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
if (!HeapTupleIsValid(classTup))
elog(ERROR, "cache lookup failed for relation %u", relOid);
classForm = (Form_pg_class) GETSTRUCT(classTup);
Assert(classForm->relnamespace == oldNspOid);
Fix ALTER EXTENSION / SET SCHEMA In its original conception, it was leaving some objects into the old schema, but without their proper pg_depend entries; this meant that the old schema could be dropped, causing future pg_dump calls to fail on the affected database. This was originally reported by Jeff Frost as #6704; there have been other complaints elsewhere that can probably be traced to this bug. To fix, be more consistent about altering a table's subsidiary objects along the table itself; this requires some restructuring in how tables are relocated when altering an extension -- hence the new AlterTableNamespaceInternal routine which encapsulates it for both the ALTER TABLE and the ALTER EXTENSION cases. There was another bug lurking here, which was unmasked after fixing the previous one: certain objects would be reached twice via the dependency graph, and the second attempt to move them would cause the entire operation to fail. Per discussion, it seems the best fix for this is to do more careful tracking of objects already moved: we now maintain a list of moved objects, to avoid attempting to do it twice for the same object. Authors: Alvaro Herrera, Dimitri Fontaine Reviewed by Tom Lane
2012-10-31 14:52:55 +01:00
thisobj.classId = RelationRelationId;
thisobj.objectId = relOid;
thisobj.objectSubId = 0;
/*
* Do nothing when there's nothing to do.
*/
if (!object_address_present(&thisobj, objsMoved))
{
/* check for duplicate name (more friendly than unique-index failure) */
if (get_relname_relid(NameStr(classForm->relname),
newNspOid) != InvalidOid)
ereport(ERROR,
(errcode(ERRCODE_DUPLICATE_TABLE),
errmsg("relation \"%s\" already exists in schema \"%s\"",
NameStr(classForm->relname),
get_namespace_name(newNspOid))));
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
Fix ALTER EXTENSION / SET SCHEMA In its original conception, it was leaving some objects into the old schema, but without their proper pg_depend entries; this meant that the old schema could be dropped, causing future pg_dump calls to fail on the affected database. This was originally reported by Jeff Frost as #6704; there have been other complaints elsewhere that can probably be traced to this bug. To fix, be more consistent about altering a table's subsidiary objects along the table itself; this requires some restructuring in how tables are relocated when altering an extension -- hence the new AlterTableNamespaceInternal routine which encapsulates it for both the ALTER TABLE and the ALTER EXTENSION cases. There was another bug lurking here, which was unmasked after fixing the previous one: certain objects would be reached twice via the dependency graph, and the second attempt to move them would cause the entire operation to fail. Per discussion, it seems the best fix for this is to do more careful tracking of objects already moved: we now maintain a list of moved objects, to avoid attempting to do it twice for the same object. Authors: Alvaro Herrera, Dimitri Fontaine Reviewed by Tom Lane
2012-10-31 14:52:55 +01:00
/* classTup is a copy, so OK to scribble on */
classForm->relnamespace = newNspOid;
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
Fix ALTER EXTENSION / SET SCHEMA In its original conception, it was leaving some objects into the old schema, but without their proper pg_depend entries; this meant that the old schema could be dropped, causing future pg_dump calls to fail on the affected database. This was originally reported by Jeff Frost as #6704; there have been other complaints elsewhere that can probably be traced to this bug. To fix, be more consistent about altering a table's subsidiary objects along the table itself; this requires some restructuring in how tables are relocated when altering an extension -- hence the new AlterTableNamespaceInternal routine which encapsulates it for both the ALTER TABLE and the ALTER EXTENSION cases. There was another bug lurking here, which was unmasked after fixing the previous one: certain objects would be reached twice via the dependency graph, and the second attempt to move them would cause the entire operation to fail. Per discussion, it seems the best fix for this is to do more careful tracking of objects already moved: we now maintain a list of moved objects, to avoid attempting to do it twice for the same object. Authors: Alvaro Herrera, Dimitri Fontaine Reviewed by Tom Lane
2012-10-31 14:52:55 +01:00
simple_heap_update(classRel, &classTup->t_self, classTup);
CatalogUpdateIndexes(classRel, classTup);
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
Fix ALTER EXTENSION / SET SCHEMA In its original conception, it was leaving some objects into the old schema, but without their proper pg_depend entries; this meant that the old schema could be dropped, causing future pg_dump calls to fail on the affected database. This was originally reported by Jeff Frost as #6704; there have been other complaints elsewhere that can probably be traced to this bug. To fix, be more consistent about altering a table's subsidiary objects along the table itself; this requires some restructuring in how tables are relocated when altering an extension -- hence the new AlterTableNamespaceInternal routine which encapsulates it for both the ALTER TABLE and the ALTER EXTENSION cases. There was another bug lurking here, which was unmasked after fixing the previous one: certain objects would be reached twice via the dependency graph, and the second attempt to move them would cause the entire operation to fail. Per discussion, it seems the best fix for this is to do more careful tracking of objects already moved: we now maintain a list of moved objects, to avoid attempting to do it twice for the same object. Authors: Alvaro Herrera, Dimitri Fontaine Reviewed by Tom Lane
2012-10-31 14:52:55 +01:00
/* Update dependency on schema if caller said so */
if (hasDependEntry &&
changeDependencyFor(RelationRelationId, relOid,
pgindent run for release 9.3 This is the first run of the Perl-based pgindent script. Also update pgindent instructions.
2013-05-29 22:58:43 +02:00
NamespaceRelationId, oldNspOid, newNspOid) != 1)
Fix ALTER EXTENSION / SET SCHEMA In its original conception, it was leaving some objects into the old schema, but without their proper pg_depend entries; this meant that the old schema could be dropped, causing future pg_dump calls to fail on the affected database. This was originally reported by Jeff Frost as #6704; there have been other complaints elsewhere that can probably be traced to this bug. To fix, be more consistent about altering a table's subsidiary objects along the table itself; this requires some restructuring in how tables are relocated when altering an extension -- hence the new AlterTableNamespaceInternal routine which encapsulates it for both the ALTER TABLE and the ALTER EXTENSION cases. There was another bug lurking here, which was unmasked after fixing the previous one: certain objects would be reached twice via the dependency graph, and the second attempt to move them would cause the entire operation to fail. Per discussion, it seems the best fix for this is to do more careful tracking of objects already moved: we now maintain a list of moved objects, to avoid attempting to do it twice for the same object. Authors: Alvaro Herrera, Dimitri Fontaine Reviewed by Tom Lane
2012-10-31 14:52:55 +01:00
elog(ERROR, "failed to change schema dependency for relation \"%s\"",
NameStr(classForm->relname));
add_exact_object_address(&thisobj, objsMoved);
Extend object-access hook machinery to support post-alter events. This also slightly widens the scope of what we support in terms of post-create events. KaiGai Kohei, with a few changes, mostly to the comments, by me
2013-03-18 03:55:14 +01:00
InvokeObjectPostAlterHook(RelationRelationId, relOid, 0);
Fix ALTER EXTENSION / SET SCHEMA In its original conception, it was leaving some objects into the old schema, but without their proper pg_depend entries; this meant that the old schema could be dropped, causing future pg_dump calls to fail on the affected database. This was originally reported by Jeff Frost as #6704; there have been other complaints elsewhere that can probably be traced to this bug. To fix, be more consistent about altering a table's subsidiary objects along the table itself; this requires some restructuring in how tables are relocated when altering an extension -- hence the new AlterTableNamespaceInternal routine which encapsulates it for both the ALTER TABLE and the ALTER EXTENSION cases. There was another bug lurking here, which was unmasked after fixing the previous one: certain objects would be reached twice via the dependency graph, and the second attempt to move them would cause the entire operation to fail. Per discussion, it seems the best fix for this is to do more careful tracking of objects already moved: we now maintain a list of moved objects, to avoid attempting to do it twice for the same object. Authors: Alvaro Herrera, Dimitri Fontaine Reviewed by Tom Lane
2012-10-31 14:52:55 +01:00
}
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
heap_freetuple(classTup);
}
/*
* Move all indexes for the specified relation to another namespace.
*
* Note: we assume adequate permission checking was done by the caller,
* and that the caller has a suitable lock on the owning relation.
*/
static void
AlterIndexNamespaces(Relation classRel, Relation rel,
Fix ALTER EXTENSION / SET SCHEMA In its original conception, it was leaving some objects into the old schema, but without their proper pg_depend entries; this meant that the old schema could be dropped, causing future pg_dump calls to fail on the affected database. This was originally reported by Jeff Frost as #6704; there have been other complaints elsewhere that can probably be traced to this bug. To fix, be more consistent about altering a table's subsidiary objects along the table itself; this requires some restructuring in how tables are relocated when altering an extension -- hence the new AlterTableNamespaceInternal routine which encapsulates it for both the ALTER TABLE and the ALTER EXTENSION cases. There was another bug lurking here, which was unmasked after fixing the previous one: certain objects would be reached twice via the dependency graph, and the second attempt to move them would cause the entire operation to fail. Per discussion, it seems the best fix for this is to do more careful tracking of objects already moved: we now maintain a list of moved objects, to avoid attempting to do it twice for the same object. Authors: Alvaro Herrera, Dimitri Fontaine Reviewed by Tom Lane
2012-10-31 14:52:55 +01:00
Oid oldNspOid, Oid newNspOid, ObjectAddresses *objsMoved)
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
{
List *indexList;
ListCell *l;
indexList = RelationGetIndexList(rel);
foreach(l, indexList)
{
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
Oid indexOid = lfirst_oid(l);
Fix ALTER EXTENSION / SET SCHEMA In its original conception, it was leaving some objects into the old schema, but without their proper pg_depend entries; this meant that the old schema could be dropped, causing future pg_dump calls to fail on the affected database. This was originally reported by Jeff Frost as #6704; there have been other complaints elsewhere that can probably be traced to this bug. To fix, be more consistent about altering a table's subsidiary objects along the table itself; this requires some restructuring in how tables are relocated when altering an extension -- hence the new AlterTableNamespaceInternal routine which encapsulates it for both the ALTER TABLE and the ALTER EXTENSION cases. There was another bug lurking here, which was unmasked after fixing the previous one: certain objects would be reached twice via the dependency graph, and the second attempt to move them would cause the entire operation to fail. Per discussion, it seems the best fix for this is to do more careful tracking of objects already moved: we now maintain a list of moved objects, to avoid attempting to do it twice for the same object. Authors: Alvaro Herrera, Dimitri Fontaine Reviewed by Tom Lane
2012-10-31 14:52:55 +01:00
ObjectAddress thisobj;
thisobj.classId = RelationRelationId;
thisobj.objectId = indexOid;
thisobj.objectSubId = 0;
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Note: currently, the index will not have its own dependency on the
* namespace, so we don't need to do changeDependencyFor(). There's no
Message style and spelling improvements
2011-06-21 23:33:20 +02:00
* row type in pg_type, either.
Fix ALTER EXTENSION / SET SCHEMA In its original conception, it was leaving some objects into the old schema, but without their proper pg_depend entries; this meant that the old schema could be dropped, causing future pg_dump calls to fail on the affected database. This was originally reported by Jeff Frost as #6704; there have been other complaints elsewhere that can probably be traced to this bug. To fix, be more consistent about altering a table's subsidiary objects along the table itself; this requires some restructuring in how tables are relocated when altering an extension -- hence the new AlterTableNamespaceInternal routine which encapsulates it for both the ALTER TABLE and the ALTER EXTENSION cases. There was another bug lurking here, which was unmasked after fixing the previous one: certain objects would be reached twice via the dependency graph, and the second attempt to move them would cause the entire operation to fail. Per discussion, it seems the best fix for this is to do more careful tracking of objects already moved: we now maintain a list of moved objects, to avoid attempting to do it twice for the same object. Authors: Alvaro Herrera, Dimitri Fontaine Reviewed by Tom Lane
2012-10-31 14:52:55 +01:00
*
* XXX this objsMoved test may be pointless -- surely we have a single
* dependency link from a relation to each index?
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
*/
Fix ALTER EXTENSION / SET SCHEMA In its original conception, it was leaving some objects into the old schema, but without their proper pg_depend entries; this meant that the old schema could be dropped, causing future pg_dump calls to fail on the affected database. This was originally reported by Jeff Frost as #6704; there have been other complaints elsewhere that can probably be traced to this bug. To fix, be more consistent about altering a table's subsidiary objects along the table itself; this requires some restructuring in how tables are relocated when altering an extension -- hence the new AlterTableNamespaceInternal routine which encapsulates it for both the ALTER TABLE and the ALTER EXTENSION cases. There was another bug lurking here, which was unmasked after fixing the previous one: certain objects would be reached twice via the dependency graph, and the second attempt to move them would cause the entire operation to fail. Per discussion, it seems the best fix for this is to do more careful tracking of objects already moved: we now maintain a list of moved objects, to avoid attempting to do it twice for the same object. Authors: Alvaro Herrera, Dimitri Fontaine Reviewed by Tom Lane
2012-10-31 14:52:55 +01:00
if (!object_address_present(&thisobj, objsMoved))
{
AlterRelationNamespaceInternal(classRel, indexOid,
oldNspOid, newNspOid,
false, objsMoved);
add_exact_object_address(&thisobj, objsMoved);
}
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
}
list_free(indexList);
}
/*
* Move all SERIAL-column sequences of the specified relation to another
* namespace.
*
* Note: we assume adequate permission checking was done by the caller,
* and that the caller has a suitable lock on the owning relation.
*/
static void
AlterSeqNamespaces(Relation classRel, Relation rel,
Fix ALTER EXTENSION / SET SCHEMA In its original conception, it was leaving some objects into the old schema, but without their proper pg_depend entries; this meant that the old schema could be dropped, causing future pg_dump calls to fail on the affected database. This was originally reported by Jeff Frost as #6704; there have been other complaints elsewhere that can probably be traced to this bug. To fix, be more consistent about altering a table's subsidiary objects along the table itself; this requires some restructuring in how tables are relocated when altering an extension -- hence the new AlterTableNamespaceInternal routine which encapsulates it for both the ALTER TABLE and the ALTER EXTENSION cases. There was another bug lurking here, which was unmasked after fixing the previous one: certain objects would be reached twice via the dependency graph, and the second attempt to move them would cause the entire operation to fail. Per discussion, it seems the best fix for this is to do more careful tracking of objects already moved: we now maintain a list of moved objects, to avoid attempting to do it twice for the same object. Authors: Alvaro Herrera, Dimitri Fontaine Reviewed by Tom Lane
2012-10-31 14:52:55 +01:00
Oid oldNspOid, Oid newNspOid, ObjectAddresses *objsMoved,
LOCKMODE lockmode)
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
{
Relation depRel;
SysScanDesc scan;
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
ScanKeyData key[2];
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
HeapTuple tup;
/*
Fix all known problems with pg_dump's handling of serial sequences 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.
2006-08-21 02:57:26 +02:00
* SERIAL sequences are those having an auto dependency on one of the
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* table's columns (we don't care *which* column, exactly).
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
*/
depRel = heap_open(DependRelationId, AccessShareLock);
ScanKeyInit(&key[0],
Anum_pg_depend_refclassid,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(RelationRelationId));
ScanKeyInit(&key[1],
Anum_pg_depend_refobjid,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(RelationGetRelid(rel)));
/* we leave refobjsubid unspecified */
scan = systable_beginscan(depRel, DependReferenceIndexId, true,
SnapshotNow, 2, key);
while (HeapTupleIsValid(tup = systable_getnext(scan)))
{
Form_pg_depend depForm = (Form_pg_depend) GETSTRUCT(tup);
Relation seqRel;
Fix all known problems with pg_dump's handling of serial sequences 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.
2006-08-21 02:57:26 +02:00
/* skip dependencies other than auto dependencies on columns */
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
if (depForm->refobjsubid == 0 ||
depForm->classid != RelationRelationId ||
depForm->objsubid != 0 ||
Fix all known problems with pg_dump's handling of serial sequences 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.
2006-08-21 02:57:26 +02:00
depForm->deptype != DEPENDENCY_AUTO)
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
continue;
/* Use relation_open just in case it's an index */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
seqRel = relation_open(depForm->objid, lockmode);
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
/* skip non-sequence relations */
if (RelationGetForm(seqRel)->relkind != RELKIND_SEQUENCE)
{
/* No need to keep the lock */
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
relation_close(seqRel, lockmode);
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
continue;
}
/* Fix the pg_class and pg_depend entries */
AlterRelationNamespaceInternal(classRel, depForm->objid,
oldNspOid, newNspOid,
Fix ALTER EXTENSION / SET SCHEMA In its original conception, it was leaving some objects into the old schema, but without their proper pg_depend entries; this meant that the old schema could be dropped, causing future pg_dump calls to fail on the affected database. This was originally reported by Jeff Frost as #6704; there have been other complaints elsewhere that can probably be traced to this bug. To fix, be more consistent about altering a table's subsidiary objects along the table itself; this requires some restructuring in how tables are relocated when altering an extension -- hence the new AlterTableNamespaceInternal routine which encapsulates it for both the ALTER TABLE and the ALTER EXTENSION cases. There was another bug lurking here, which was unmasked after fixing the previous one: certain objects would be reached twice via the dependency graph, and the second attempt to move them would cause the entire operation to fail. Per discussion, it seems the best fix for this is to do more careful tracking of objects already moved: we now maintain a list of moved objects, to avoid attempting to do it twice for the same object. Authors: Alvaro Herrera, Dimitri Fontaine Reviewed by Tom Lane
2012-10-31 14:52:55 +01:00
true, objsMoved);
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Sequences have entries in pg_type. We need to be careful to move
* them to the new namespace, too.
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
*/
AlterTypeNamespaceInternal(RelationGetForm(seqRel)->reltype,
Fix ALTER EXTENSION / SET SCHEMA In its original conception, it was leaving some objects into the old schema, but without their proper pg_depend entries; this meant that the old schema could be dropped, causing future pg_dump calls to fail on the affected database. This was originally reported by Jeff Frost as #6704; there have been other complaints elsewhere that can probably be traced to this bug. To fix, be more consistent about altering a table's subsidiary objects along the table itself; this requires some restructuring in how tables are relocated when altering an extension -- hence the new AlterTableNamespaceInternal routine which encapsulates it for both the ALTER TABLE and the ALTER EXTENSION cases. There was another bug lurking here, which was unmasked after fixing the previous one: certain objects would be reached twice via the dependency graph, and the second attempt to move them would cause the entire operation to fail. Per discussion, it seems the best fix for this is to do more careful tracking of objects already moved: we now maintain a list of moved objects, to avoid attempting to do it twice for the same object. Authors: Alvaro Herrera, Dimitri Fontaine Reviewed by Tom Lane
2012-10-31 14:52:55 +01:00
newNspOid, false, false, objsMoved);
Add ALTER object SET SCHEMA capability for a limited but useful set of object kinds (tables, functions, types). Documentation is not here yet. Original code by Bernd Helmle, extensive rework by Bruce Momjian and Tom Lane.
2005-08-01 06:03:59 +02:00
/* Now we can close it. Keep the lock till end of transaction. */
relation_close(seqRel, NoLock);
}
systable_endscan(scan);
relation_close(depRel, AccessShareLock);
}
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
/*
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
* This code supports
* CREATE TEMP TABLE ... ON COMMIT { DROP | PRESERVE ROWS | DELETE ROWS }
*
* Because we only support this for TEMP tables, it's sufficient to remember
* the state in a backend-local data structure.
*/
/*
* Register a newly-created relation's ON COMMIT action.
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
*/
void
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
register_on_commit_action(Oid relid, OnCommitAction action)
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
{
pgindent run.
2003-08-04 02:43:34 +02:00
OnCommitItem *oc;
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
MemoryContext oldcxt;
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* We needn't bother registering the relation unless there is an ON COMMIT
* action we need to take.
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
*/
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
if (action == ONCOMMIT_NOOP || action == ONCOMMIT_PRESERVE_ROWS)
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
return;
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
oldcxt = MemoryContextSwitchTo(CacheMemoryContext);
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
oc = (OnCommitItem *) palloc(sizeof(OnCommitItem));
oc->relid = relid;
oc->oncommit = action;
Restructure subtransaction handling to reduce resource consumption, as per recent discussions. Invent SubTransactionIds that are managed like CommandIds (ie, counter is reset at start of each top transaction), and use these instead of TransactionIds to keep track of subtransaction status in those modules that need it. This means that a subtransaction does not need an XID unless it actually inserts/modifies rows in the database. Accordingly, don't assign it an XID nor take a lock on the XID until it tries to do that. This saves a lot of overhead for subtransactions that are only used for error recovery (eg plpgsql exceptions). Also, arrange to release a subtransaction's XID lock as soon as the subtransaction exits, in both the commit and abort cases. This avoids holding many unique locks after a long series of subtransactions. The price is some additional overhead in XactLockTableWait, but that seems acceptable. Finally, restructure the state machine in xact.c to have a more orthogonal set of states for subtransactions.
2004-09-16 18:58:44 +02:00
oc->creating_subid = GetCurrentSubTransactionId();
oc->deleting_subid = InvalidSubTransactionId;
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
on_commits = lcons(oc, on_commits);
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
MemoryContextSwitchTo(oldcxt);
}
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
/*
* Unregister any ON COMMIT action when a relation is deleted.
*
* Actually, we only mark the OnCommitItem entry as to be deleted after commit.
*/
void
remove_on_commit_action(Oid relid)
{
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *l;
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
foreach(l, on_commits)
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
{
pgindent run.
2003-08-04 02:43:34 +02:00
OnCommitItem *oc = (OnCommitItem *) lfirst(l);
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
if (oc->relid == relid)
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
{
Restructure subtransaction handling to reduce resource consumption, as per recent discussions. Invent SubTransactionIds that are managed like CommandIds (ie, counter is reset at start of each top transaction), and use these instead of TransactionIds to keep track of subtransaction status in those modules that need it. This means that a subtransaction does not need an XID unless it actually inserts/modifies rows in the database. Accordingly, don't assign it an XID nor take a lock on the XID until it tries to do that. This saves a lot of overhead for subtransactions that are only used for error recovery (eg plpgsql exceptions). Also, arrange to release a subtransaction's XID lock as soon as the subtransaction exits, in both the commit and abort cases. This avoids holding many unique locks after a long series of subtransactions. The price is some additional overhead in XactLockTableWait, but that seems acceptable. Finally, restructure the state machine in xact.c to have a more orthogonal set of states for subtransactions.
2004-09-16 18:58:44 +02:00
oc->deleting_subid = GetCurrentSubTransactionId();
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
break;
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
}
}
}
/*
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
* Perform ON COMMIT actions.
*
* This is invoked just before actually committing, since it's possible
* to encounter errors.
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
*/
void
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
PreCommit_on_commit_actions(void)
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
{
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *l;
Generalize TRUNCATE to support truncating multiple tables in one command. This is useful because we can allow truncation of tables referenced by foreign keys, so long as the referencing table is truncated in the same command. Alvaro Herrera
2005-01-27 04:19:37 +01:00
List *oids_to_truncate = NIL;
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
foreach(l, on_commits)
{
pgindent run.
2003-08-04 02:43:34 +02:00
OnCommitItem *oc = (OnCommitItem *) lfirst(l);
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
/* Ignore entry if already dropped in this xact */
Restructure subtransaction handling to reduce resource consumption, as per recent discussions. Invent SubTransactionIds that are managed like CommandIds (ie, counter is reset at start of each top transaction), and use these instead of TransactionIds to keep track of subtransaction status in those modules that need it. This means that a subtransaction does not need an XID unless it actually inserts/modifies rows in the database. Accordingly, don't assign it an XID nor take a lock on the XID until it tries to do that. This saves a lot of overhead for subtransactions that are only used for error recovery (eg plpgsql exceptions). Also, arrange to release a subtransaction's XID lock as soon as the subtransaction exits, in both the commit and abort cases. This avoids holding many unique locks after a long series of subtransactions. The price is some additional overhead in XactLockTableWait, but that seems acceptable. Finally, restructure the state machine in xact.c to have a more orthogonal set of states for subtransactions.
2004-09-16 18:58:44 +02:00
if (oc->deleting_subid != InvalidSubTransactionId)
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
continue;
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
switch (oc->oncommit)
{
case ONCOMMIT_NOOP:
case ONCOMMIT_PRESERVE_ROWS:
/* Do nothing (there shouldn't be such entries, actually) */
break;
case ONCOMMIT_DELETE_ROWS:
pgindent run for release 9.3 This is the first run of the Perl-based pgindent script. Also update pgindent instructions.
2013-05-29 22:58:43 +02:00
Skip truncating ON COMMIT DELETE ROWS temp tables, if the transaction hasn't touched any temporary tables. We could try harder, and keep track of whether we've inserted to any temp tables, rather than accessed them, and which temp tables have been inserted to. But this is dead simple, and already covers many interesting scenarios.
2013-01-29 09:40:22 +01:00
/*
* If this transaction hasn't accessed any temporary
* relations, we can skip truncating ON COMMIT DELETE ROWS
* tables, as they must still be empty.
*/
if (MyXactAccessedTempRel)
oids_to_truncate = lappend_oid(oids_to_truncate, oc->relid);
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
break;
case ONCOMMIT_DROP:
pgindent run.
2003-08-04 02:43:34 +02:00
{
ObjectAddress object;
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
First phase of project to use fixed OIDs for all system catalogs and indexes. Extend the macros in include/catalog/*.h to carry the info about hand-assigned OIDs, and adjust the genbki script and bootstrap code to make the relations actually get those OIDs. Remove the small number of RelOid_pg_foo macros that we had in favor of a complete set named like the catname.h and indexing.h macros. Next phase will get rid of internal use of names for looking up catalogs and indexes; but this completes the changes forcing an initdb, so it looks like a good place to commit. Along the way, I made the shared relations (pg_database etc) not be 'bootstrap' relations any more, so as to reduce the number of hardwired entries and simplify changing those relations in future. I'm not sure whether they ever really needed to be handled as bootstrap relations, but it seems to work fine to not do so now.
2005-04-14 03:38:22 +02:00
object.classId = RelationRelationId;
pgindent run.
2003-08-04 02:43:34 +02:00
object.objectId = oc->relid;
object.objectSubId = 0;
Classify DROP operations by whether or not they are user-initiated. This doesn't do anything useful just yet, but is intended as supporting infrastructure for allowing sepgsql to sensibly check DROP permissions. KaiGai Kohei and Robert Haas
2012-01-26 15:24:54 +01:00
/*
* Since this is an automatic drop, rather than one
* directly initiated by the user, we pass the
* PERFORM_DELETION_INTERNAL flag.
*/
performDeletion(&object,
DROP_CASCADE, PERFORM_DELETION_INTERNAL);
pgindent run.
2003-08-04 02:43:34 +02:00
/*
* Note that table deletion will call
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* remove_on_commit_action, so the entry should get marked
* as deleted.
pgindent run.
2003-08-04 02:43:34 +02:00
*/
Restructure subtransaction handling to reduce resource consumption, as per recent discussions. Invent SubTransactionIds that are managed like CommandIds (ie, counter is reset at start of each top transaction), and use these instead of TransactionIds to keep track of subtransaction status in those modules that need it. This means that a subtransaction does not need an XID unless it actually inserts/modifies rows in the database. Accordingly, don't assign it an XID nor take a lock on the XID until it tries to do that. This saves a lot of overhead for subtransactions that are only used for error recovery (eg plpgsql exceptions). Also, arrange to release a subtransaction's XID lock as soon as the subtransaction exits, in both the commit and abort cases. This avoids holding many unique locks after a long series of subtransactions. The price is some additional overhead in XactLockTableWait, but that seems acceptable. Finally, restructure the state machine in xact.c to have a more orthogonal set of states for subtransactions.
2004-09-16 18:58:44 +02:00
Assert(oc->deleting_subid != InvalidSubTransactionId);
pgindent run.
2003-08-04 02:43:34 +02:00
break;
}
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
}
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
}
Generalize TRUNCATE to support truncating multiple tables in one command. This is useful because we can allow truncation of tables referenced by foreign keys, so long as the referencing table is truncated in the same command. Alvaro Herrera
2005-01-27 04:19:37 +01:00
if (oids_to_truncate != NIL)
{
heap_truncate(oids_to_truncate);
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
CommandCounterIncrement(); /* XXX needed? */
Generalize TRUNCATE to support truncating multiple tables in one command. This is useful because we can allow truncation of tables referenced by foreign keys, so long as the referencing table is truncated in the same command. Alvaro Herrera
2005-01-27 04:19:37 +01:00
}
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
}
/*
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
* Post-commit or post-abort cleanup for ON COMMIT management.
*
* All we do here is remove no-longer-needed OnCommitItem entries.
*
* During commit, remove entries that were deleted during this transaction;
* during abort, remove those created during this transaction.
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
*/
void
Restructure subtransaction handling to reduce resource consumption, as per recent discussions. Invent SubTransactionIds that are managed like CommandIds (ie, counter is reset at start of each top transaction), and use these instead of TransactionIds to keep track of subtransaction status in those modules that need it. This means that a subtransaction does not need an XID unless it actually inserts/modifies rows in the database. Accordingly, don't assign it an XID nor take a lock on the XID until it tries to do that. This saves a lot of overhead for subtransactions that are only used for error recovery (eg plpgsql exceptions). Also, arrange to release a subtransaction's XID lock as soon as the subtransaction exits, in both the commit and abort cases. This avoids holding many unique locks after a long series of subtransactions. The price is some additional overhead in XactLockTableWait, but that seems acceptable. Finally, restructure the state machine in xact.c to have a more orthogonal set of states for subtransactions.
2004-09-16 18:58:44 +02:00
AtEOXact_on_commit_actions(bool isCommit)
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
ListCell *cur_item;
ListCell *prev_item;
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
prev_item = NULL;
cur_item = list_head(on_commits);
while (cur_item != NULL)
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
{
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
OnCommitItem *oc = (OnCommitItem *) lfirst(cur_item);
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
Restructure subtransaction handling to reduce resource consumption, as per recent discussions. Invent SubTransactionIds that are managed like CommandIds (ie, counter is reset at start of each top transaction), and use these instead of TransactionIds to keep track of subtransaction status in those modules that need it. This means that a subtransaction does not need an XID unless it actually inserts/modifies rows in the database. Accordingly, don't assign it an XID nor take a lock on the XID until it tries to do that. This saves a lot of overhead for subtransactions that are only used for error recovery (eg plpgsql exceptions). Also, arrange to release a subtransaction's XID lock as soon as the subtransaction exits, in both the commit and abort cases. This avoids holding many unique locks after a long series of subtransactions. The price is some additional overhead in XactLockTableWait, but that seems acceptable. Finally, restructure the state machine in xact.c to have a more orthogonal set of states for subtransactions.
2004-09-16 18:58:44 +02:00
if (isCommit ? oc->deleting_subid != InvalidSubTransactionId :
oc->creating_subid != InvalidSubTransactionId)
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
{
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
/* cur_item must be removed */
on_commits = list_delete_cell(on_commits, cur_item, prev_item);
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
pfree(oc);
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
if (prev_item)
cur_item = lnext(prev_item);
else
cur_item = list_head(on_commits);
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
}
else
{
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
/* cur_item must be preserved */
Restructure subtransaction handling to reduce resource consumption, as per recent discussions. Invent SubTransactionIds that are managed like CommandIds (ie, counter is reset at start of each top transaction), and use these instead of TransactionIds to keep track of subtransaction status in those modules that need it. This means that a subtransaction does not need an XID unless it actually inserts/modifies rows in the database. Accordingly, don't assign it an XID nor take a lock on the XID until it tries to do that. This saves a lot of overhead for subtransactions that are only used for error recovery (eg plpgsql exceptions). Also, arrange to release a subtransaction's XID lock as soon as the subtransaction exits, in both the commit and abort cases. This avoids holding many unique locks after a long series of subtransactions. The price is some additional overhead in XactLockTableWait, but that seems acceptable. Finally, restructure the state machine in xact.c to have a more orthogonal set of states for subtransactions.
2004-09-16 18:58:44 +02:00
oc->creating_subid = InvalidSubTransactionId;
oc->deleting_subid = InvalidSubTransactionId;
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
prev_item = cur_item;
cur_item = lnext(prev_item);
}
}
}
/*
* Post-subcommit or post-subabort cleanup for ON COMMIT management.
*
* During subabort, we can immediately remove entries created during this
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
* subtransaction. During subcommit, just relabel entries marked during
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
* this subtransaction as being the parent's responsibility.
*/
void
Restructure subtransaction handling to reduce resource consumption, as per recent discussions. Invent SubTransactionIds that are managed like CommandIds (ie, counter is reset at start of each top transaction), and use these instead of TransactionIds to keep track of subtransaction status in those modules that need it. This means that a subtransaction does not need an XID unless it actually inserts/modifies rows in the database. Accordingly, don't assign it an XID nor take a lock on the XID until it tries to do that. This saves a lot of overhead for subtransactions that are only used for error recovery (eg plpgsql exceptions). Also, arrange to release a subtransaction's XID lock as soon as the subtransaction exits, in both the commit and abort cases. This avoids holding many unique locks after a long series of subtransactions. The price is some additional overhead in XactLockTableWait, but that seems acceptable. Finally, restructure the state machine in xact.c to have a more orthogonal set of states for subtransactions.
2004-09-16 18:58:44 +02:00
AtEOSubXact_on_commit_actions(bool isCommit, SubTransactionId mySubid,
SubTransactionId parentSubid)
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
ListCell *cur_item;
ListCell *prev_item;
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
prev_item = NULL;
cur_item = list_head(on_commits);
while (cur_item != NULL)
{
OnCommitItem *oc = (OnCommitItem *) lfirst(cur_item);
Restructure subtransaction handling to reduce resource consumption, as per recent discussions. Invent SubTransactionIds that are managed like CommandIds (ie, counter is reset at start of each top transaction), and use these instead of TransactionIds to keep track of subtransaction status in those modules that need it. This means that a subtransaction does not need an XID unless it actually inserts/modifies rows in the database. Accordingly, don't assign it an XID nor take a lock on the XID until it tries to do that. This saves a lot of overhead for subtransactions that are only used for error recovery (eg plpgsql exceptions). Also, arrange to release a subtransaction's XID lock as soon as the subtransaction exits, in both the commit and abort cases. This avoids holding many unique locks after a long series of subtransactions. The price is some additional overhead in XactLockTableWait, but that seems acceptable. Finally, restructure the state machine in xact.c to have a more orthogonal set of states for subtransactions.
2004-09-16 18:58:44 +02:00
if (!isCommit && oc->creating_subid == mySubid)
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
{
/* cur_item must be removed */
on_commits = list_delete_cell(on_commits, cur_item, prev_item);
pfree(oc);
if (prev_item)
cur_item = lnext(prev_item);
else
cur_item = list_head(on_commits);
}
else
{
/* cur_item must be preserved */
Restructure subtransaction handling to reduce resource consumption, as per recent discussions. Invent SubTransactionIds that are managed like CommandIds (ie, counter is reset at start of each top transaction), and use these instead of TransactionIds to keep track of subtransaction status in those modules that need it. This means that a subtransaction does not need an XID unless it actually inserts/modifies rows in the database. Accordingly, don't assign it an XID nor take a lock on the XID until it tries to do that. This saves a lot of overhead for subtransactions that are only used for error recovery (eg plpgsql exceptions). Also, arrange to release a subtransaction's XID lock as soon as the subtransaction exits, in both the commit and abort cases. This avoids holding many unique locks after a long series of subtransactions. The price is some additional overhead in XactLockTableWait, but that seems acceptable. Finally, restructure the state machine in xact.c to have a more orthogonal set of states for subtransactions.
2004-09-16 18:58:44 +02:00
if (oc->creating_subid == mySubid)
oc->creating_subid = parentSubid;
if (oc->deleting_subid == mySubid)
oc->deleting_subid = isCommit ? parentSubid : InvalidSubTransactionId;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
prev_item = cur_item;
cur_item = lnext(prev_item);
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
}
}
}
Improve behavior of concurrent CLUSTER. In the previous coding, a user could queue up for an AccessExclusiveLock on a table they did not have permission to cluster, thus potentially interfering with access by authorized users who got stuck waiting behind the AccessExclusiveLock. This approach avoids that. cluster() has the same permissions-checking requirements as REINDEX TABLE, so this commit moves the now-shared callback to tablecmds.c and renames it, per discussion with Noah Misch.
2011-12-21 21:17:28 +01:00
/*
* This is intended as a callback for RangeVarGetRelidExtended(). It allows
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
* the relation to be locked only if (1) it's a plain table, materialized
* view, or TOAST table and (2) the current user is the owner (or the
pgindent run for release 9.3 This is the first run of the Perl-based pgindent script. Also update pgindent instructions.
2013-05-29 22:58:43 +02:00
* superuser). This meets the permission-checking needs of CLUSTER, REINDEX
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
* TABLE, and REFRESH MATERIALIZED VIEW; we expose it here so that it can be
* used by all.
Improve behavior of concurrent CLUSTER. In the previous coding, a user could queue up for an AccessExclusiveLock on a table they did not have permission to cluster, thus potentially interfering with access by authorized users who got stuck waiting behind the AccessExclusiveLock. This approach avoids that. cluster() has the same permissions-checking requirements as REINDEX TABLE, so this commit moves the now-shared callback to tablecmds.c and renames it, per discussion with Noah Misch.
2011-12-21 21:17:28 +01:00
*/
void
RangeVarCallbackOwnsTable(const RangeVar *relation,
Oid relId, Oid oldRelId, void *arg)
{
char relkind;
/* Nothing to do if the relation was not found. */
if (!OidIsValid(relId))
return;
/*
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* If the relation does exist, check whether it's an index. But note that
* the relation might have been dropped between the time we did the name
* lookup and now. In that case, there's nothing to do.
Improve behavior of concurrent CLUSTER. In the previous coding, a user could queue up for an AccessExclusiveLock on a table they did not have permission to cluster, thus potentially interfering with access by authorized users who got stuck waiting behind the AccessExclusiveLock. This approach avoids that. cluster() has the same permissions-checking requirements as REINDEX TABLE, so this commit moves the now-shared callback to tablecmds.c and renames it, per discussion with Noah Misch.
2011-12-21 21:17:28 +01:00
*/
relkind = get_rel_relkind(relId);
if (!relkind)
return;
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
if (relkind != RELKIND_RELATION && relkind != RELKIND_TOASTVALUE &&
relkind != RELKIND_MATVIEW)
Improve behavior of concurrent CLUSTER. In the previous coding, a user could queue up for an AccessExclusiveLock on a table they did not have permission to cluster, thus potentially interfering with access by authorized users who got stuck waiting behind the AccessExclusiveLock. This approach avoids that. cluster() has the same permissions-checking requirements as REINDEX TABLE, so this commit moves the now-shared callback to tablecmds.c and renames it, per discussion with Noah Misch.
2011-12-21 21:17:28 +01:00
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
errmsg("\"%s\" is not a table or materialized view", relation->relname)));
Improve behavior of concurrent CLUSTER. In the previous coding, a user could queue up for an AccessExclusiveLock on a table they did not have permission to cluster, thus potentially interfering with access by authorized users who got stuck waiting behind the AccessExclusiveLock. This approach avoids that. cluster() has the same permissions-checking requirements as REINDEX TABLE, so this commit moves the now-shared callback to tablecmds.c and renames it, per discussion with Noah Misch.
2011-12-21 21:17:28 +01:00
/* Check permissions */
if (!pg_class_ownercheck(relId, GetUserId()))
aclcheck_error(ACLCHECK_NOT_OWNER, ACL_KIND_CLASS, relation->relname);
}
Improve behavior of concurrent ALTER TABLE, and do some refactoring. ALTER TABLE (and ALTER VIEW, ALTER SEQUENCE, etc.) now use a RangeVarGetRelid callback to check permissions before acquiring a table lock. We also now use the same callback for all forms of ALTER TABLE, rather than having separate, almost-identical callbacks for ALTER TABLE .. SET SCHEMA and ALTER TABLE .. RENAME, and no callback at all for everything else. I went ahead and changed the code so that no form of ALTER TABLE works on foreign tables; you must use ALTER FOREIGN TABLE instead. In 9.1, it was possible to use ALTER TABLE .. SET SCHEMA or ALTER TABLE .. RENAME on a foreign table, but not any other form of ALTER TABLE, which did not seem terribly useful or consistent. Patch by me; review by Noah Misch.
2012-01-07 04:42:26 +01:00
/*
* Common RangeVarGetRelid callback for rename, set schema, and alter table
* processing.
*/
static void
RangeVarCallbackForAlterRelation(const RangeVar *rv, Oid relid, Oid oldrelid,
void *arg)
{
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
Node *stmt = (Node *) arg;
ObjectType reltype;
HeapTuple tuple;
Form_pg_class classform;
AclResult aclresult;
char relkind;
Improve behavior of concurrent ALTER TABLE, and do some refactoring. ALTER TABLE (and ALTER VIEW, ALTER SEQUENCE, etc.) now use a RangeVarGetRelid callback to check permissions before acquiring a table lock. We also now use the same callback for all forms of ALTER TABLE, rather than having separate, almost-identical callbacks for ALTER TABLE .. SET SCHEMA and ALTER TABLE .. RENAME, and no callback at all for everything else. I went ahead and changed the code so that no form of ALTER TABLE works on foreign tables; you must use ALTER FOREIGN TABLE instead. In 9.1, it was possible to use ALTER TABLE .. SET SCHEMA or ALTER TABLE .. RENAME on a foreign table, but not any other form of ALTER TABLE, which did not seem terribly useful or consistent. Patch by me; review by Noah Misch.
2012-01-07 04:42:26 +01:00
tuple = SearchSysCache1(RELOID, ObjectIdGetDatum(relid));
if (!HeapTupleIsValid(tuple))
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
return; /* concurrently dropped */
Improve behavior of concurrent ALTER TABLE, and do some refactoring. ALTER TABLE (and ALTER VIEW, ALTER SEQUENCE, etc.) now use a RangeVarGetRelid callback to check permissions before acquiring a table lock. We also now use the same callback for all forms of ALTER TABLE, rather than having separate, almost-identical callbacks for ALTER TABLE .. SET SCHEMA and ALTER TABLE .. RENAME, and no callback at all for everything else. I went ahead and changed the code so that no form of ALTER TABLE works on foreign tables; you must use ALTER FOREIGN TABLE instead. In 9.1, it was possible to use ALTER TABLE .. SET SCHEMA or ALTER TABLE .. RENAME on a foreign table, but not any other form of ALTER TABLE, which did not seem terribly useful or consistent. Patch by me; review by Noah Misch.
2012-01-07 04:42:26 +01:00
classform = (Form_pg_class) GETSTRUCT(tuple);
relkind = classform->relkind;
/* Must own relation. */
if (!pg_class_ownercheck(relid, GetUserId()))
aclcheck_error(ACLCHECK_NOT_OWNER, ACL_KIND_CLASS, rv->relname);
/* No system table modifications unless explicitly allowed. */
if (!allowSystemTableMods && IsSystemClass(classform))
ereport(ERROR,
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
errmsg("permission denied: \"%s\" is a system catalog",
rv->relname)));
/*
* Extract the specified relation type from the statement parse tree.
*
* Also, for ALTER .. RENAME, check permissions: the user must (still)
* have CREATE rights on the containing namespace.
*/
if (IsA(stmt, RenameStmt))
{
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
aclresult = pg_namespace_aclcheck(classform->relnamespace,
Improve behavior of concurrent ALTER TABLE, and do some refactoring. ALTER TABLE (and ALTER VIEW, ALTER SEQUENCE, etc.) now use a RangeVarGetRelid callback to check permissions before acquiring a table lock. We also now use the same callback for all forms of ALTER TABLE, rather than having separate, almost-identical callbacks for ALTER TABLE .. SET SCHEMA and ALTER TABLE .. RENAME, and no callback at all for everything else. I went ahead and changed the code so that no form of ALTER TABLE works on foreign tables; you must use ALTER FOREIGN TABLE instead. In 9.1, it was possible to use ALTER TABLE .. SET SCHEMA or ALTER TABLE .. RENAME on a foreign table, but not any other form of ALTER TABLE, which did not seem terribly useful or consistent. Patch by me; review by Noah Misch.
2012-01-07 04:42:26 +01:00
GetUserId(), ACL_CREATE);
if (aclresult != ACLCHECK_OK)
aclcheck_error(aclresult, ACL_KIND_NAMESPACE,
get_namespace_name(classform->relnamespace));
reltype = ((RenameStmt *) stmt)->renameType;
}
else if (IsA(stmt, AlterObjectSchemaStmt))
reltype = ((AlterObjectSchemaStmt *) stmt)->objectType;
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
Improve behavior of concurrent ALTER TABLE, and do some refactoring. ALTER TABLE (and ALTER VIEW, ALTER SEQUENCE, etc.) now use a RangeVarGetRelid callback to check permissions before acquiring a table lock. We also now use the same callback for all forms of ALTER TABLE, rather than having separate, almost-identical callbacks for ALTER TABLE .. SET SCHEMA and ALTER TABLE .. RENAME, and no callback at all for everything else. I went ahead and changed the code so that no form of ALTER TABLE works on foreign tables; you must use ALTER FOREIGN TABLE instead. In 9.1, it was possible to use ALTER TABLE .. SET SCHEMA or ALTER TABLE .. RENAME on a foreign table, but not any other form of ALTER TABLE, which did not seem terribly useful or consistent. Patch by me; review by Noah Misch.
2012-01-07 04:42:26 +01:00
else if (IsA(stmt, AlterTableStmt))
reltype = ((AlterTableStmt *) stmt)->relkind;
else
{
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
reltype = OBJECT_TABLE; /* placate compiler */
Improve behavior of concurrent ALTER TABLE, and do some refactoring. ALTER TABLE (and ALTER VIEW, ALTER SEQUENCE, etc.) now use a RangeVarGetRelid callback to check permissions before acquiring a table lock. We also now use the same callback for all forms of ALTER TABLE, rather than having separate, almost-identical callbacks for ALTER TABLE .. SET SCHEMA and ALTER TABLE .. RENAME, and no callback at all for everything else. I went ahead and changed the code so that no form of ALTER TABLE works on foreign tables; you must use ALTER FOREIGN TABLE instead. In 9.1, it was possible to use ALTER TABLE .. SET SCHEMA or ALTER TABLE .. RENAME on a foreign table, but not any other form of ALTER TABLE, which did not seem terribly useful or consistent. Patch by me; review by Noah Misch.
2012-01-07 04:42:26 +01:00
elog(ERROR, "unrecognized node type: %d", (int) nodeTag(stmt));
}
/*
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* For compatibility with prior releases, we allow ALTER TABLE to be used
* with most other types of relations (but not composite types). We allow
* similar flexibility for ALTER INDEX in the case of RENAME, but not
* otherwise. Otherwise, the user must select the correct form of the
* command for the relation at issue.
Improve behavior of concurrent ALTER TABLE, and do some refactoring. ALTER TABLE (and ALTER VIEW, ALTER SEQUENCE, etc.) now use a RangeVarGetRelid callback to check permissions before acquiring a table lock. We also now use the same callback for all forms of ALTER TABLE, rather than having separate, almost-identical callbacks for ALTER TABLE .. SET SCHEMA and ALTER TABLE .. RENAME, and no callback at all for everything else. I went ahead and changed the code so that no form of ALTER TABLE works on foreign tables; you must use ALTER FOREIGN TABLE instead. In 9.1, it was possible to use ALTER TABLE .. SET SCHEMA or ALTER TABLE .. RENAME on a foreign table, but not any other form of ALTER TABLE, which did not seem terribly useful or consistent. Patch by me; review by Noah Misch.
2012-01-07 04:42:26 +01:00
*/
if (reltype == OBJECT_SEQUENCE && relkind != RELKIND_SEQUENCE)
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("\"%s\" is not a sequence", rv->relname)));
if (reltype == OBJECT_VIEW && relkind != RELKIND_VIEW)
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("\"%s\" is not a view", rv->relname)));
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
if (reltype == OBJECT_MATVIEW && relkind != RELKIND_MATVIEW)
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("\"%s\" is not a materialized view", rv->relname)));
Improve behavior of concurrent ALTER TABLE, and do some refactoring. ALTER TABLE (and ALTER VIEW, ALTER SEQUENCE, etc.) now use a RangeVarGetRelid callback to check permissions before acquiring a table lock. We also now use the same callback for all forms of ALTER TABLE, rather than having separate, almost-identical callbacks for ALTER TABLE .. SET SCHEMA and ALTER TABLE .. RENAME, and no callback at all for everything else. I went ahead and changed the code so that no form of ALTER TABLE works on foreign tables; you must use ALTER FOREIGN TABLE instead. In 9.1, it was possible to use ALTER TABLE .. SET SCHEMA or ALTER TABLE .. RENAME on a foreign table, but not any other form of ALTER TABLE, which did not seem terribly useful or consistent. Patch by me; review by Noah Misch.
2012-01-07 04:42:26 +01:00
if (reltype == OBJECT_FOREIGN_TABLE && relkind != RELKIND_FOREIGN_TABLE)
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("\"%s\" is not a foreign table", rv->relname)));
if (reltype == OBJECT_TYPE && relkind != RELKIND_COMPOSITE_TYPE)
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("\"%s\" is not a composite type", rv->relname)));
if (reltype == OBJECT_INDEX && relkind != RELKIND_INDEX
&& !IsA(stmt, RenameStmt))
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("\"%s\" is not an index", rv->relname)));
/*
* Don't allow ALTER TABLE on composite types. We want people to use ALTER
* TYPE for that.
*/
if (reltype != OBJECT_TYPE && relkind == RELKIND_COMPOSITE_TYPE)
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("\"%s\" is a composite type", rv->relname),
errhint("Use ALTER TYPE instead.")));
/*
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* Don't allow ALTER TABLE .. SET SCHEMA on relations that can't be moved
* to a different schema, such as indexes and TOAST tables.
Improve behavior of concurrent ALTER TABLE, and do some refactoring. ALTER TABLE (and ALTER VIEW, ALTER SEQUENCE, etc.) now use a RangeVarGetRelid callback to check permissions before acquiring a table lock. We also now use the same callback for all forms of ALTER TABLE, rather than having separate, almost-identical callbacks for ALTER TABLE .. SET SCHEMA and ALTER TABLE .. RENAME, and no callback at all for everything else. I went ahead and changed the code so that no form of ALTER TABLE works on foreign tables; you must use ALTER FOREIGN TABLE instead. In 9.1, it was possible to use ALTER TABLE .. SET SCHEMA or ALTER TABLE .. RENAME on a foreign table, but not any other form of ALTER TABLE, which did not seem terribly useful or consistent. Patch by me; review by Noah Misch.
2012-01-07 04:42:26 +01:00
*/
Allow CREATE FOREIGN TABLE to include SERIAL columns. The behavior is that the required sequence is created locally, which is appropriate because the default expression will be evaluated locally. Per gripe from Brad Nicholson that this case was refused with a confusing error message. We could have improved the error message but it seems better to just allow the case. Also, remove ALTER TABLE's arbitrary prohibition against being applied to foreign tables, which was pretty inconsistent considering we allow it for views, sequences, and other relation types that aren't even called tables. This is needed to avoid breaking pg_dump, which sometimes emits column defaults using separate ALTER TABLE commands. (I think this can happen even when the default is not associated with a sequence, so that was a pre-existing bug once we allowed column defaults for foreign tables.)
2013-05-16 01:03:29 +02:00
if (IsA(stmt, AlterObjectSchemaStmt) &&
relkind != RELKIND_RELATION &&
relkind != RELKIND_VIEW &&
relkind != RELKIND_MATVIEW &&
relkind != RELKIND_SEQUENCE &&
relkind != RELKIND_FOREIGN_TABLE)
Improve behavior of concurrent ALTER TABLE, and do some refactoring. ALTER TABLE (and ALTER VIEW, ALTER SEQUENCE, etc.) now use a RangeVarGetRelid callback to check permissions before acquiring a table lock. We also now use the same callback for all forms of ALTER TABLE, rather than having separate, almost-identical callbacks for ALTER TABLE .. SET SCHEMA and ALTER TABLE .. RENAME, and no callback at all for everything else. I went ahead and changed the code so that no form of ALTER TABLE works on foreign tables; you must use ALTER FOREIGN TABLE instead. In 9.1, it was possible to use ALTER TABLE .. SET SCHEMA or ALTER TABLE .. RENAME on a foreign table, but not any other form of ALTER TABLE, which did not seem terribly useful or consistent. Patch by me; review by Noah Misch.
2012-01-07 04:42:26 +01:00
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("\"%s\" is not a table, view, sequence, or foreign table",
rv->relname)));
ReleaseSysCache(tuple);
}