Index: doc/src/sgml/advanced.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/advanced.sgml,v retrieving revision 1.31 diff -c -r1.31 advanced.sgml *** doc/src/sgml/advanced.sgml 11 Nov 2002 20:14:02 -0000 1.31 --- doc/src/sgml/advanced.sgml 18 Feb 2003 02:13:27 -0000 *************** *** 41,47 **** Refer back to the queries in . Suppose the combined listing of weather records and city location ! is of particular interest to your application, but you don't want to type the query each time you need it. You can create a view over the query, which gives a name to the query that you can refer to like an ordinary table. --- 41,47 ---- Refer back to the queries in . Suppose the combined listing of weather records and city location ! is of particular interest to your application, but you do not want to type the query each time you need it. You can create a view over the query, which gives a name to the query that you can refer to like an ordinary table. *************** *** 232,238 **** ! If, partway through the transaction, we decide we don't want to commit (perhaps we just noticed that Alice's balance went negative), we can issue the command ROLLBACK instead of COMMIT, and all our updates so far will be canceled. --- 232,238 ---- ! If, partway through the transaction, we decide we do not want to commit (perhaps we just noticed that Alice's balance went negative), we can issue the command ROLLBACK instead of COMMIT, and all our updates so far will be canceled. *************** *** 240,246 **** PostgreSQL actually treats every SQL statement as being ! executed within a transaction. If you don't issue a BEGIN command, then each individual statement has an implicit BEGIN and (if successful) COMMIT wrapped around it. A group of --- 240,246 ---- PostgreSQL actually treats every SQL statement as being ! executed within a transaction. If you do not issue a BEGIN command, then each individual statement has an implicit BEGIN and (if successful) COMMIT wrapped around it. A group of Index: doc/src/sgml/arch-dev.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/arch-dev.sgml,v retrieving revision 2.17 diff -c -r2.17 arch-dev.sgml *** doc/src/sgml/arch-dev.sgml 19 Jan 2003 00:13:28 -0000 2.17 --- doc/src/sgml/arch-dev.sgml 18 Feb 2003 02:47:14 -0000 *************** *** 17,31 **** This chapter gives an overview of the internal structure of the ! backend of PostgreSQL. ! After having read the following sections you ! should have an idea of how a query is processed. Don't expect a ! detailed description here (I think such a description dealing with ! all data structures and functions used within PostgreSQL ! would exceed 1000 ! pages!). This chapter is intended to help understanding the general ! control and data flow within the backend from receiving a query to ! sending the results. --- 17,31 ---- This chapter gives an overview of the internal structure of the ! backend of PostgreSQL. After having ! read the following sections you should have an idea of how a query ! is processed. This chapter does not aim to provide a detailed ! description of the internal operation of ! PostgreSQL, as such a document would be ! very extensive. Rather, this chapter is intended to help the reader ! understand the general sequence of operations that occur within the ! backend from the point at which a query is received, to the point ! when the results are returned to the client. *************** *** 118,140 **** How Connections are Established ! PostgreSQL is implemented using a simple "process per-user" ! client/server model. In this model there is one client process ! connected to exactly one server process. ! As we don't know per se ! how many connections will be made, we have to use a master process ! that spawns a new server process every time a connection is ! requested. This master process is called postmaster and ! listens at a specified TCP/IP port for incoming connections. Whenever ! a request for a connection is detected the postmaster process ! spawns a new server process called postgres. The server ! tasks (postgres processes) communicate with each other using ! semaphores and shared memory ! to ensure data integrity ! throughout concurrent data access. Figure ! \ref{connection} illustrates the interaction of the master process ! postmaster the server process postgres and a client ! application. --- 118,142 ---- How Connections are Established ! PostgreSQL is implemented using a ! simple "process per-user" client/server model. In this model ! there is one client process connected to ! exactly one server process. As we do not ! know ahead of time how many connections will be made, we have to ! use a master process that spawns a new ! server process every time a connection is requested. This master ! process is called postmaster and listens at a ! specified TCP/IP port for incoming connections. Whenever a request ! for a connection is detected the postmaster ! process spawns a new server process called ! postgres. The server tasks ! (postgres processes) communicate with each ! other using semaphores and ! shared memory to ensure data integrity ! throughout concurrent data access. Figure \ref{connection} ! illustrates the interaction of the master process ! postmaster the server process ! postgres and a client application. *************** *** 686,692 **** for the varno fields in the VAR nodes appearing in the mergeclauses list (and also in the targetlist) mean that not the tuples of the current node should be ! considered but the tuples of the next "deeper" nodes (i.e. the top nodes of the subplans) should be used instead. --- 688,694 ---- for the varno fields in the VAR nodes appearing in the mergeclauses list (and also in the targetlist) mean that not the tuples of the current node should be ! considered but the tuples of the next deeper nodes (i.e. the top nodes of the subplans) should be used instead. Index: doc/src/sgml/datatype.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/datatype.sgml,v retrieving revision 1.113 diff -c -r1.113 datatype.sgml *** doc/src/sgml/datatype.sgml 31 Jan 2003 01:08:07 -0000 1.113 --- doc/src/sgml/datatype.sgml 18 Feb 2003 02:16:48 -0000 *************** *** 895,901 **** actual string, and in case of character plus the padding. Long strings are compressed by the system automatically, so the physical requirement on disk may be less. Long values are also ! stored in background tables so they don't interfere with rapid access to the shorter column values. In any case, the longest possible character string that can be stored is about 1 GB. (The maximum value that will be allowed for n in the data --- 895,901 ---- actual string, and in case of character plus the padding. Long strings are compressed by the system automatically, so the physical requirement on disk may be less. Long values are also ! stored in background tables so they do not interfere with rapid access to the shorter column values. In any case, the longest possible character string that can be stored is about 1 GB. (The maximum value that will be allowed for n in the data Index: doc/src/sgml/ddl.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/ddl.sgml,v retrieving revision 1.10 diff -c -r1.10 ddl.sgml *** doc/src/sgml/ddl.sgml 15 Nov 2002 03:11:15 -0000 1.10 --- doc/src/sgml/ddl.sgml 18 Feb 2003 02:18:00 -0000 *************** *** 115,122 **** ! If you don't need a table anymore, you can remove it using the ! DROP TABLE command. For example: DROP TABLE my_first_table; DROP TABLE products; --- 115,122 ---- ! If you no longer need a table, you can remove it using the ! DROP TABLE command. For example: DROP TABLE my_first_table; DROP TABLE products; *************** *** 718,724 **** We know that the foreign keys disallow creation of orders that ! don't relate to any products. But what if a product is removed after an order is created that references it? SQL allows you to specify that as well. Intuitively, we have a few options: --- 718,724 ---- We know that the foreign keys disallow creation of orders that ! do not relate to any products. But what if a product is removed after an order is created that references it? SQL allows you to specify that as well. Intuitively, we have a few options: *************** *** 759,765 **** Restricting and cascading deletes are the two most common options. RESTRICT can also be written as NO ! ACTION and it's also the default if you don't specify anything. There are two other options for what should happen with the foreign key columns when a primary key is deleted: SET NULL and SET DEFAULT. --- 759,765 ---- Restricting and cascading deletes are the two most common options. RESTRICT can also be written as NO ! ACTION and it's also the default if you do not specify anything. There are two other options for what should happen with the foreign key columns when a primary key is deleted: SET NULL and SET DEFAULT. *************** *** 1602,1608 **** In the SQL standard, the notion of objects in the same schema being owned by different users does not exist. Moreover, some ! implementations don't allow you to create schemas that have a different name than their owner. In fact, the concepts of schema and user are nearly equivalent in a database system that implements only the basic schema support specified in the --- 1602,1608 ---- In the SQL standard, the notion of objects in the same schema being owned by different users does not exist. Moreover, some ! implementations do not allow you to create schemas that have a different name than their owner. In fact, the concepts of schema and user are nearly equivalent in a database system that implements only the basic schema support specified in the *************** *** 1686,1692 **** ERROR: Cannot drop table products because other objects depend on it Use DROP ... CASCADE to drop the dependent objects too ! The error message contains a useful hint: If you don't want to bother deleting all the dependent objects individually, you can run DROP TABLE products CASCADE; --- 1686,1692 ---- ERROR: Cannot drop table products because other objects depend on it Use DROP ... CASCADE to drop the dependent objects too ! The error message contains a useful hint: if you do not want to bother deleting all the dependent objects individually, you can run DROP TABLE products CASCADE; Index: doc/src/sgml/docguide.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/docguide.sgml,v retrieving revision 1.42 diff -c -r1.42 docguide.sgml *** doc/src/sgml/docguide.sgml 28 Jul 2002 15:22:20 -0000 1.42 --- doc/src/sgml/docguide.sgml 18 Feb 2003 02:18:17 -0000 *************** *** 1327,1333 **** If the program uses 0 for success and non-zero for failure, ! then you don't need to document it. If there is a meaning behind the different non-zero exit codes, list them here. --- 1327,1333 ---- If the program uses 0 for success and non-zero for failure, ! then you do not need to document it. If there is a meaning behind the different non-zero exit codes, list them here. Index: doc/src/sgml/mvcc.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/mvcc.sgml,v retrieving revision 2.32 diff -c -r2.32 mvcc.sgml *** doc/src/sgml/mvcc.sgml 11 Jan 2003 00:00:02 -0000 2.32 --- doc/src/sgml/mvcc.sgml 18 Feb 2003 02:19:00 -0000 *************** *** 38,46 **** ! The main difference between multiversion and lock models is that ! in MVCC locks acquired for querying (reading) ! data don't conflict with locks acquired for writing data, and so reading never blocks writing and writing never blocks reading. --- 38,47 ---- ! The main advantage to using the MVCC model of ! concurrency control rather than locking is that in ! MVCC locks acquired for querying (reading) data ! do not conflict with locks acquired for writing data, and so reading never blocks writing and writing never blocks reading. *************** *** 437,446 **** ! The SELECT command acquires a ! lock of this mode on referenced tables. In general, any query ! that only reads a table and does not modify it will acquire ! this lock mode. --- 438,447 ---- ! The commands SELECT and ! ANALYZE acquire a lock of this mode on ! referenced tables. In general, any query that only reads a table ! and does not modify it will acquire this lock mode. *************** *** 586,594 **** Acquired by the ALTER TABLE, DROP ! TABLE, and VACUUM FULL commands. ! This is also the default lock mode for LOCK TABLE ! statements that do not specify a mode explicitly. --- 587,596 ---- Acquired by the ALTER TABLE, DROP ! TABLE, REINDEX, ! CLUSTER, and VACUUM FULL ! commands. This is also the default lock mode for LOCK ! TABLE statements that do not specify a mode explicitly. *************** *** 612,618 **** A row-level lock on a specific row is automatically acquired when the row is updated (or deleted or marked for update). The lock is held until the transaction commits or rolls back. ! Row-level locks don't affect data querying; they block writers to the same row only. To acquire a row-level lock on a row without actually modifying the row, select the row with SELECT FOR --- 614,620 ---- A row-level lock on a specific row is automatically acquired when the row is updated (or deleted or marked for update). The lock is held until the transaction commits or rolls back. ! Row-level locks do not affect data querying; they block writers to the same row only. To acquire a row-level lock on a row without actually modifying the row, select the row with SELECT FOR *************** *** 726,732 **** Because readers in PostgreSQL ! don't lock data, regardless of transaction isolation level, data read by one transaction can be overwritten by another concurrent transaction. In other words, if a row is returned by SELECT it doesn't mean that --- 728,734 ---- Because readers in PostgreSQL ! do not lock data, regardless of transaction isolation level, data read by one transaction can be overwritten by another concurrent transaction. In other words, if a row is returned by SELECT it doesn't mean that Index: doc/src/sgml/page.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/page.sgml,v retrieving revision 1.12 diff -c -r1.12 page.sgml *** doc/src/sgml/page.sgml 2 Sep 2002 01:05:03 -0000 1.12 --- doc/src/sgml/page.sgml 18 Feb 2003 02:27:06 -0000 *************** *** 196,204 **** ! The final section is the "special section" which may contain anything the ! access method wishes to store. Ordinary tables do not use this at all ! (indicated by setting pd_special to equal the pagesize). --- 196,205 ---- ! The final section is the special section which may ! contain anything the access method wishes to store. Ordinary tables ! do not use this at all (indicated by setting ! pd_special to equal the pagesize). Index: doc/src/sgml/plpgsql.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/plpgsql.sgml,v retrieving revision 1.14 diff -c -r1.14 plpgsql.sgml *** doc/src/sgml/plpgsql.sgml 19 Jan 2003 00:13:28 -0000 1.14 --- doc/src/sgml/plpgsql.sgml 18 Feb 2003 02:19:30 -0000 *************** *** 578,584 **** ! By using %TYPE you don't need to know the data type of the structure you are referencing, and most important, if the data type of the referenced item changes in the future (e.g: you --- 578,584 ---- ! By using %TYPE you do not need to know the data type of the structure you are referencing, and most important, if the data type of the referenced item changes in the future (e.g: you *************** *** 1649,1655 **** up a cursor that encapsulates the query, and then read the query result a few rows at a time. One reason for doing this is to avoid memory overrun when the result contains a large number of ! rows. (However, PL/pgSQL users don't normally need to worry about that, since FOR loops automatically use a cursor internally to avoid memory problems.) A more interesting usage is to return a reference to a cursor that it has created, allowing the --- 1649,1655 ---- up a cursor that encapsulates the query, and then read the query result a few rows at a time. One reason for doing this is to avoid memory overrun when the result contains a large number of ! rows. (However, PL/pgSQL users do not normally need to worry about that, since FOR loops automatically use a cursor internally to avoid memory problems.) A more interesting usage is to return a reference to a cursor that it has created, allowing the Index: doc/src/sgml/runtime.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/runtime.sgml,v retrieving revision 1.168 diff -c -r1.168 runtime.sgml *** doc/src/sgml/runtime.sgml 6 Feb 2003 20:25:31 -0000 1.168 --- doc/src/sgml/runtime.sgml 18 Feb 2003 02:21:12 -0000 *************** *** 122,128 **** However, while the directory contents are secure, the default client authentication setup allows any local user to connect to the ! database and even become the database superuser. If you don't trust other local users, we recommend you use initdb's or option to assign a password to the database superuser. After initdb, --- 122,128 ---- However, while the directory contents are secure, the default client authentication setup allows any local user to connect to the ! database and even become the database superuser. If you do not trust other local users, we recommend you use initdb's or option to assign a password to the database superuser. After initdb, *************** *** 365,371 **** probably means your kernel's limit on the size of shared memory is smaller than the buffer area PostgreSQL is trying to create (83918612 bytes in this example). Or it could ! mean that you don't have System-V-style shared memory support configured into your kernel at all. As a temporary workaround, you can try starting the postmaster with a smaller-than-normal number of buffers ( switch). You will eventually want --- 365,371 ---- probably means your kernel's limit on the size of shared memory is smaller than the buffer area PostgreSQL is trying to create (83918612 bytes in this example). Or it could ! mean that you do not have System-V-style shared memory support configured into your kernel at all. As a temporary workaround, you can try starting the postmaster with a smaller-than-normal number of buffers ( switch). You will eventually want *************** *** 2937,2943 **** On the other side of the coin, some systems allow individual processes to open large numbers of files; if more than a few processes do so then the system-wide limit can easily be exceeded. ! If you find this happening, and don't want to alter the system-wide limit, you can set PostgreSQL's max_files_per_process configuration parameter to limit the consumption of open files. --- 2937,2943 ---- On the other side of the coin, some systems allow individual processes to open large numbers of files; if more than a few processes do so then the system-wide limit can easily be exceeded. ! If you find this happening, and you do not want to alter the system-wide limit, you can set PostgreSQL's max_files_per_process configuration parameter to limit the consumption of open files. Index: doc/src/sgml/sql.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/sql.sgml,v retrieving revision 1.28 diff -c -r1.28 sql.sgml *** doc/src/sgml/sql.sgml 15 Jan 2003 18:01:05 -0000 1.28 --- doc/src/sgml/sql.sgml 18 Feb 2003 02:33:25 -0000 *************** *** 24,30 **** SQL has become the most popular relational query language. ! The name "SQL" is an abbreviation for Structured Query Language. In 1974 Donald Chamberlin and others defined the language SEQUEL (Structured English Query --- 24,30 ---- SQL has become the most popular relational query language. ! The name SQL is an abbreviation for Structured Query Language. In 1974 Donald Chamberlin and others defined the language SEQUEL (Structured English Query *************** *** 72,81 **** (ISO). This original standard version of SQL is often referred to, ! informally, as "SQL/86". In 1989 the original standard was extended and this new standard is often, again informally, referred to as ! "SQL/89". Also in 1989, a related standard called Database Language Embedded SQL (ESQL) was developed. --- 72,81 ---- (ISO). This original standard version of SQL is often referred to, ! informally, as SQL/86. In 1989 the original standard was extended and this new standard is often, again informally, referred to as ! SQL/89. Also in 1989, a related standard called Database Language Embedded SQL (ESQL) was developed. *************** *** 86,96 **** definition of a greatly expanded version of the original standard, referred to informally as SQL2 or SQL/92. This version became a ! ratified standard - "International Standard ISO/IEC 9075:1992, ! Database Language SQL" - in late 1992. SQL/92 is the version ! normally meant when people refer to "the SQL ! standard". A detailed description of SQL/92 is given in . At the time of writing this document a new standard informally referred to --- 86,96 ---- definition of a greatly expanded version of the original standard, referred to informally as SQL2 or SQL/92. This version became a ! ratified standard - International Standard ISO/IEC 9075:1992, ! Database Language SQL - in late 1992. SQL/92 is the version ! normally meant when people refer to the SQL ! standard. A detailed description of SQL/92 is given in . At the time of writing this document a new standard informally referred to *************** *** 768,775 **** can be formulated using relational algebra can also be formulated using the relational calculus and vice versa. This was first proved by E. F. Codd in ! 1972. This proof is based on an algorithm ("Codd's reduction ! algorithm") by which an arbitrary expression of the relational calculus can be reduced to a semantically equivalent expression of relational algebra. For a more detailed discussion on that refer to --- 768,775 ---- can be formulated using relational algebra can also be formulated using the relational calculus and vice versa. This was first proved by E. F. Codd in ! 1972. This proof is based on an algorithm (Codd's reduction ! algorithm) by which an arbitrary expression of the relational calculus can be reduced to a semantically equivalent expression of relational algebra. For a more detailed discussion on that refer to *************** *** 778,788 **** ! It is sometimes said that languages based on the relational calculus ! are "higher level" or "more declarative" than languages based on ! relational algebra because the algebra (partially) specifies the order ! of operations while the calculus leaves it to a compiler or ! interpreter to determine the most efficient order of evaluation. --- 778,789 ---- ! It is sometimes said that languages based on the relational ! calculus are higher level or more ! declarative than languages based on relational algebra ! because the algebra (partially) specifies the order of operations ! while the calculus leaves it to a compiler or interpreter to ! determine the most efficient order of evaluation. *************** *** 870,878 **** ! Now we will illustrate the complex syntax of the SELECT statement ! with various examples. The tables used for the examples are defined in ! . --- 871,880 ---- ! Now we will illustrate the complex syntax of the ! SELECT statement with various examples. The ! tables used for the examples are defined in . *************** *** 903,909 **** ! Using "*" in the SELECT statement will deliver all attributes from the table. If we want to retrieve only the attributes PNAME and PRICE from table PART we use the statement: --- 905,911 ---- ! Using * in the SELECT statement will deliver all attributes from the table. If we want to retrieve only the attributes PNAME and PRICE from table PART we use the statement: *************** *** 922,930 **** Cam | 25 ! Note that the SQL SELECT corresponds to the ! "projection" in relational algebra not to the "selection" ! (see for more details). --- 924,933 ---- Cam | 25 ! Note that the SQL SELECT corresponds to the ! projection in relational algebra not to the ! selection (see for more details). Index: doc/src/sgml/start.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/start.sgml,v retrieving revision 1.27 diff -c -r1.27 start.sgml *** doc/src/sgml/start.sgml 11 Nov 2002 20:14:04 -0000 1.27 --- doc/src/sgml/start.sgml 18 Feb 2003 02:22:50 -0000 *************** *** 242,248 **** ! If you don't want to use your database anymore you can remove it. For example, if you are the owner (creator) of the database mydb, you can destroy it using the following command: --- 242,248 ---- ! If you do not want to use your database anymore you can remove it. For example, if you are the owner (creator) of the database mydb, you can destroy it using the following command: Index: doc/src/sgml/typeconv.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/typeconv.sgml,v retrieving revision 1.25 diff -c -r1.25 typeconv.sgml *** doc/src/sgml/typeconv.sgml 11 Nov 2002 20:14:04 -0000 1.25 --- doc/src/sgml/typeconv.sgml 18 Feb 2003 02:26:38 -0000 *************** *** 305,311 **** If any input arguments are unknown, check the type categories accepted at those argument positions by the remaining ! candidates. At each position, select the "string" category if any candidate accepts that category (this bias towards string is appropriate since an unknown-type literal does look like a string). Otherwise, if all the remaining candidates accept the same type category, select that --- 305,311 ---- If any input arguments are unknown, check the type categories accepted at those argument positions by the remaining ! candidates. At each position, select the string category if any candidate accepts that category (this bias towards string is appropriate since an unknown-type literal does look like a string). Otherwise, if all the remaining candidates accept the same type category, select that Index: doc/src/sgml/xfunc.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/xfunc.sgml,v retrieving revision 1.64 diff -c -r1.64 xfunc.sgml *** doc/src/sgml/xfunc.sgml 19 Jan 2003 00:13:28 -0000 1.64 --- doc/src/sgml/xfunc.sgml 18 Feb 2003 02:26:09 -0000 *************** *** 606,612 **** The newer version 1 calling convention is indicated by writing a PG_FUNCTION_INFO_V1() macro call for the function, as illustrated below. Lack of such a macro indicates an old-style ! ("version 0") function. The language name specified in CREATE FUNCTION is C in either case. Old-style functions are now deprecated because of portability problems and lack of functionality, but they are still supported for compatibility reasons. --- 606,612 ---- The newer version 1 calling convention is indicated by writing a PG_FUNCTION_INFO_V1() macro call for the function, as illustrated below. Lack of such a macro indicates an old-style ! (version 0) function. The language name specified in CREATE FUNCTION is C in either case. Old-style functions are now deprecated because of portability problems and lack of functionality, but they are still supported for compatibility reasons. *************** *** 1380,1386 **** zero, and a negative length requests that the remainder of the value be returned. These routines provide more efficient access to parts of large values in the case where they have storage type ! "external". (The storage type of a column can be specified using ALTER TABLE tablename ALTER COLUMN colname SET STORAGE storagetype. Storage type is one of --- 1380,1386 ---- zero, and a negative length requests that the remainder of the value be returned. These routines provide more efficient access to parts of large values in the case where they have storage type ! external. (The storage type of a column can be specified using ALTER TABLE tablename ALTER COLUMN colname SET STORAGE storagetype. Storage type is one of *************** *** 1583,1589 **** HeapTuple BuildTupleFromCStrings(AttInMetadata *attinmeta, char **values) can be used to build a HeapTuple given user data ! in C string form. "values" is an array of C strings, one for each attribute of the return tuple. Each C string should be in the form expected by the input function of the attribute data type. In order to return a null value for one of the attributes, --- 1583,1589 ---- HeapTuple BuildTupleFromCStrings(AttInMetadata *attinmeta, char **values) can be used to build a HeapTuple given user data ! in C string form. values is an array of C strings, one for each attribute of the return tuple. Each C string should be in the form expected by the input function of the attribute data type. In order to return a null value for one of the attributes, Index: doc/src/sgml/ref/alter_table.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/ref/alter_table.sgml,v retrieving revision 1.55 diff -c -r1.55 alter_table.sgml *** doc/src/sgml/ref/alter_table.sgml 13 Feb 2003 05:19:59 -0000 1.55 --- doc/src/sgml/ref/alter_table.sgml 18 Feb 2003 02:00:26 -0000 *************** *** 367,373 **** default and NOT NULL clauses for the new column are not supported. The new column always comes into being with all values NULL. You can use the SET DEFAULT form ! of ALTER TABLE to set the default afterwards. (You may also want to update the already existing rows to the new default value, using .) --- 367,373 ---- default and NOT NULL clauses for the new column are not supported. The new column always comes into being with all values NULL. You can use the SET DEFAULT form ! of ALTER TABLE to set the default afterward. (You may also want to update the already existing rows to the new default value, using .) *************** *** 392,410 **** ! If a table has any descendant tables, it is not permitted to ADD or ! RENAME a column in the parent table without doing the same to the ! descendants --- that is, ALTER TABLE ONLY will be rejected. This ! ensures that the descendants always have columns matching the parent. ! A recursive DROP COLUMN operation will remove a descendant table's column ! only if the descendant does not inherit that column from any other ! parents and never had an independent definition of the column. ! A nonrecursive DROP COLUMN (i.e., ALTER TABLE ONLY ... DROP COLUMN) ! never removes any descendant columns, but instead marks them as ! independently defined rather than inherited. --- 392,412 ---- ! If a table has any descendant tables, it is not permitted to ADD ! or RENAME a column in the parent table without doing the same to ! the descendants --- that is, ALTER TABLE ONLY ! will be rejected. This ensures that the descendants always have ! columns matching the parent. ! A recursive DROP COLUMN operation will remove a ! descendant table's column only if the descendant does not inherit ! that column from any other parents and never had an independent ! definition of the column. A nonrecursive DROP ! COLUMN (i.e., ALTER TABLE ONLY ... DROP ! COLUMN) never removes any descendant columns, but ! instead marks them as independently defined rather than inherited. Index: doc/src/sgml/ref/cluster.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/ref/cluster.sgml,v retrieving revision 1.23 diff -c -r1.23 cluster.sgml *** doc/src/sgml/ref/cluster.sgml 30 Dec 2002 18:42:12 -0000 1.23 --- doc/src/sgml/ref/cluster.sgml 18 Feb 2003 02:03:14 -0000 *************** *** 117,127 **** CLUSTER without any parameter re-clusters all the tables in the current database that the calling user owns, or all tables if called ! by a superuser. (Never-clustered tables are not touched.) This form of CLUSTER cannot be called from inside a transaction or function. 1998-09-08 --- 117,135 ---- CLUSTER without any parameter re-clusters all the tables in the current database that the calling user owns, or all tables if called ! by a superuser. (Never-clustered tables are not included.) This form of CLUSTER cannot be called from inside a transaction or function. + + When a table is being clustered, an ACCESS + EXCLUSIVE lock is acquired on it. This prevents any other + database operations (both reads and writes) from preceding on the + table until the CLUSTER is finished. See the + &cite-user; for more information on database locking. + + 1998-09-08 *************** *** 159,166 **** ! CLUSTER preserves GRANT, inheritance, index, foreign ! key, and other ancillary information about the table. --- 167,175 ---- ! CLUSTER preserves GRANT, ! inheritance, index, foreign key, and other ancillary information ! about the table. *************** *** 212,224 **** Usage ! Cluster the employees relation on the basis of its ID attribute: CLUSTER emp_ind ON emp; ! Cluster the employees relation using the same index that was used before: CLUSTER emp; --- 221,235 ---- Usage ! Cluster the employees relation on the basis of ! its ID attribute: CLUSTER emp_ind ON emp; ! Cluster the employees relation using the same ! index that was used before: CLUSTER emp; *************** *** 247,252 **** --- 258,271 ---- There is no CLUSTER statement in SQL92. + + + + See Also + + + + Index: doc/src/sgml/ref/clusterdb.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/ref/clusterdb.sgml,v retrieving revision 1.6 diff -c -r1.6 clusterdb.sgml *** doc/src/sgml/ref/clusterdb.sgml 13 Feb 2003 05:37:43 -0000 1.6 --- doc/src/sgml/ref/clusterdb.sgml 18 Feb 2003 02:10:43 -0000 *************** *** 37,43 **** in a PostgreSQL database. It finds tables that have previously been clustered, and clusters them again on the same index that was last used. Tables that have never been clustered are not ! touched. --- 37,43 ---- in a PostgreSQL database. It finds tables that have previously been clustered, and clusters them again on the same index that was last used. Tables that have never been clustered are not ! affected. Index: doc/src/sgml/ref/reindex.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/ref/reindex.sgml,v retrieving revision 1.14 diff -c -r1.14 reindex.sgml *** doc/src/sgml/ref/reindex.sgml 17 Nov 2002 23:43:32 -0000 1.14 --- doc/src/sgml/ref/reindex.sgml 18 Feb 2003 01:34:32 -0000 *************** *** 38,45 **** DATABASE ! Recreate all system indexes of a specified database. ! (User-table indexes are not included.) --- 38,46 ---- DATABASE ! Recreate all system indexes of a specified database. Indexes on ! user tables are not included. This form of REINDEX can ! only be used in standalone mode (see below). *************** *** 116,131 **** Description ! REINDEX is used to rebuild corrupted indexes. ! Although in theory this should never be necessary, in practice ! indexes may become corrupted due to software bugs or hardware ! failures. REINDEX provides a recovery method. ! ! ! REINDEX also removes certain dead index pages that ! can't be reclaimed any other way. See the "Routine Reindexing" ! section in the manual for more information. --- 117,151 ---- Description ! REINDEX rebuilds an index based on the data ! stored in the table, replacing the old copy of the index. There are ! two main reasons to use REINDEX: ! ! ! ! An index has become corrupted, and no longer contains valid ! data. Although in theory this should never be necessary, in ! practice indexes may become corrupted due to software bugs or ! hardware failures. REINDEX provides a ! recovery method. ! ! ! ! ! ! The index in question contains a lot of dead index pages that ! are not being reclaimed. This can occur with B+-tree indexes ! under certain access patterns. REINDEX ! provides a way to reduce the space consumption of the index by ! writing a new version of the index without the dead pages. See ! the Routine Reindexing section in the ! &cite-admin; for more information. The rest of this section ! mostly discusses how to use REINDEX to ! recover from index corruption. ! ! ! Index: doc/src/sgml/ref/set_session_auth.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/ref/set_session_auth.sgml,v retrieving revision 1.7 diff -c -r1.7 set_session_auth.sgml *** doc/src/sgml/ref/set_session_auth.sgml 21 Sep 2002 18:32:54 -0000 1.7 --- doc/src/sgml/ref/set_session_auth.sgml 18 Feb 2003 01:43:45 -0000 *************** *** 16,22 **** ! SET [ SESSION | LOCAL ] SESSION AUTHORIZATION username SET [ SESSION | LOCAL ] SESSION AUTHORIZATION DEFAULT RESET SESSION AUTHORIZATION --- 16,22 ---- ! SET [ SESSION | LOCAL ] SESSION AUTHORIZATION username SET [ SESSION | LOCAL ] SESSION AUTHORIZATION DEFAULT RESET SESSION AUTHORIZATION *************** *** 27,38 **** This command sets the session user identifier and the current user ! identifier of the current SQL-session context to be ! username. The user name may be written as ! either an identifier or a string literal. ! The session user identifier is valid for the duration of a ! connection; for example, it is possible to temporarily become an ! unprivileged user and later switch back to become a superuser. --- 27,38 ---- This command sets the session user identifier and the current user ! identifier of the current SQL-session context to be username. The user name may be ! written as either an identifier or a string literal. The session ! user identifier is valid for the duration of a connection; for ! example, it is possible to temporarily become an unprivileged user ! and later switch back to become a superuser. *************** *** 68,86 **** Examples ! ! SELECT SESSION_USER, CURRENT_USER; ! current_user | session_user --------------+-------------- peter | peter ! SET SESSION AUTHORIZATION 'paul'; ! SELECT SESSION_USER, CURRENT_USER; ! current_user | session_user --------------+-------------- paul | paul ! --- 68,88 ---- Examples ! ! SELECT SESSION_USER, CURRENT_USER; ! ! session_user | current_user --------------+-------------- peter | peter ! SET SESSION AUTHORIZATION 'paul'; ! ! SELECT SESSION_USER, CURRENT_USER; ! session_user | current_user --------------+-------------- paul | paul ! Index: doc/src/sgml/ref/vacuum.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/ref/vacuum.sgml,v retrieving revision 1.28 diff -c -r1.28 vacuum.sgml *** doc/src/sgml/ref/vacuum.sgml 19 Jan 2003 00:13:31 -0000 1.28 --- doc/src/sgml/ref/vacuum.sgml 18 Feb 2003 02:03:58 -0000 *************** *** 286,291 **** --- 286,299 ---- + + + See Also + + + + +