From: Thomas G. Lockhart Date: Wed, 21 Nov 2001 06:09:45 +0000 (+0000) Subject: Deprecate 'current' date/time constant. X-Git-Tag: REL7_2_BETA4~213 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=6c402eafc863f8358651a94c4951112b57c9ed01;p=thirdparty%2Fpostgresql.git Deprecate 'current' date/time constant. Purge "Postgres" in favor of "PostgreSQL" in docs. ref/ not yet done. --- diff --git a/doc/src/sgml/reference.sgml b/doc/src/sgml/reference.sgml index e4c85ed699f..fd038179741 100644 --- a/doc/src/sgml/reference.sgml +++ b/doc/src/sgml/reference.sgml @@ -1,5 +1,5 @@ @@ -128,7 +128,7 @@ Disable this chapter until we have more functions documented. This part provides reference information for the SQL functions supported by - Postgres. + PostgreSQL. ¤tDate; diff --git a/doc/src/sgml/release.sgml b/doc/src/sgml/release.sgml index 453d2c3f271..a85ff6d4028 100644 --- a/doc/src/sgml/release.sgml +++ b/doc/src/sgml/release.sgml @@ -1,5 +1,5 @@ @@ -829,7 +829,7 @@ ecpg changes (Michael) A dump/restore using pg_dump is required for those wishing to migrate data from any - previous release of Postgres. + previous release of PostgreSQL. For those upgrading from 6.5.*, you may instead use pg_upgrade to upgrade to this release; however, a full dump/reload installation is always the @@ -848,7 +848,7 @@ ecpg changes (Michael) SQL92-defined types timestamp and interval. Although there has been some effort to ease the transition by allowing - Postgres to recognize + PostgreSQL to recognize the deprecated type names and translate them to the new type names, this mechanism may not be completely transparent to your existing application. @@ -1554,7 +1554,7 @@ Add Win1250 (Czech) support (Pavel Behal) chapter on troubleshooting from Tom Lane. And the Programmer's Guide has a description of query processing, also from Stefan, and details - on obtaining the Postgres source + on obtaining the PostgreSQL source tree via anonymous CVS and CVSup. @@ -1569,7 +1569,7 @@ Add Win1250 (Czech) support (Pavel Behal) A dump/restore using pg_dump is required for those wishing to migrate data from any - previous release of Postgres. + previous release of PostgreSQL. pg_upgrade can not be used to upgrade to this release because the on-disk structure of the tables has changed compared to previous releases. @@ -1602,7 +1602,7 @@ Add Win1250 (Czech) support (Pavel Behal) concurrent updates one must use SELECT FOR UPDATE or an appropriate LOCK TABLE statement. This should be taken into account when porting applications from previous releases of - Postgres and other environments. + PostgreSQL and other environments. @@ -1986,7 +1986,7 @@ asynchronous messages and interrupts thanks to Tom Lane. The parser will now perform automatic type coercion to match arguments to available operators and functions, and to match columns and expressions with target columns. This uses a generic mechanism which supports -the type extensibility features of Postgres. +the type extensibility features of PostgreSQL. There is a new chapter in the User's Guide which covers this topic. @@ -2029,7 +2029,7 @@ been. A dump/restore using pg_dump or pg_dumpall is required for those wishing to migrate data from any -previous release of Postgres. +previous release of PostgreSQL. @@ -2281,7 +2281,7 @@ Correctly handles function calls on the left side of BETWEEN and LIKE clauses. A dump/restore is NOT required for those running 6.3 or 6.3.1. A make distclean, make, and make install is all that is required. This last step should be performed while the postmaster is not running. -You should re-link any custom applications that use Postgres libraries. +You should re-link any custom applications that use PostgreSQL libraries. For upgrades from pre-6.3 installations, @@ -2369,7 +2369,7 @@ Improvements to the configuration autodetection for installation. A dump/restore is NOT required for those running 6.3. A make distclean, make, and make install is all that is required. This last step should be performed while the postmaster is not running. -You should re-link any custom applications that use Postgres libraries. +You should re-link any custom applications that use PostgreSQL libraries. For upgrades from pre-6.3 installations, @@ -2542,7 +2542,7 @@ Better identify tcl and tk libs and includes(Bruce) \d command for types, operators, etc. Also, views have their own permissions now, not based on the underlying tables, so permissions on them have to be set separately. Check /pgsql/interfaces for some new - ways to talk to Postgres. + ways to talk to PostgreSQL. This is the first release that really required an explanation for @@ -2558,7 +2558,7 @@ Better identify tcl and tk libs and includes(Bruce) A dump/restore using pg_dump or pg_dumpall is required for those wishing to migrate data from any - previous release of Postgres. + previous release of PostgreSQL. @@ -2615,7 +2615,7 @@ Modify constraint syntax to be SQL92-compliant(Thomas) Implement SQL92 PRIMARY KEY and UNIQUE clauses using indexes(Thomas) Recognize SQL92 syntax for FOREIGN KEY. Throw elog notice(Thomas) Allow NOT NULL UNIQUE constraint clause (each allowed separately before)(Thomas) -Allow Postgres-style casting ("::") of non-constants(Thomas) +Allow PostgreSQL-style casting ("::") of non-constants(Thomas) Add support for SQL3 TRUE and FALSE boolean constants(Thomas) Support SQL92 syntax for IS TRUE/IS FALSE/IS NOT TRUE/IS NOT FALSE(Thomas) Allow shorter strings for boolean literals (e.g. "t", "tr", "tru")(Thomas) @@ -2628,7 +2628,7 @@ Use shared lock when building indexes(Vadim) Free memory allocated for an user query inside transaction block after this query is done, was turned off in <= 6.2.1(Vadim) New SQL statement CREATE PROCEDURAL LANGUAGE(Jan) -New Postgres Procedural Language (PL) backend interface(Jan) +New PostgreSQL Procedural Language (PL) backend interface(Jan) Rename pg_dump -H option to -h(Bruce) Add Java support for passwords, European dates(Peter) Use indexes for LIKE and ~, !~ operations(Bruce) @@ -2637,7 +2637,7 @@ Time Travel removed(Vadim, Bruce) Add paging for \d and \z, and fix \i(Bruce) Add Unix domain socket support to backend and to frontend library(Goran) Implement CREATE DATABASE/WITH LOCATION and initlocation utility(Thomas) -Allow more SQL92 and/or Postgres reserved words as column identifiers(Thomas) +Allow more SQL92 and/or PostgreSQL reserved words as column identifiers(Thomas) Augment support for SQL92 SET TIME ZONE...(Thomas) SET/SHOW/RESET TIME ZONE uses TZ backend environment variable(Thomas) Implement SET keyword = DEFAULT and SET TIME ZONE DEFAULT(Thomas) @@ -2850,7 +2850,7 @@ Trigger function for inserting user names for INSERT/UPDATE(Brook Milligan) A dump/restore is required for those wishing to migrate data from -previous releases of Postgres. +previous releases of PostgreSQL. @@ -3071,19 +3071,19 @@ pg_dumpall now returns proper status, portability fix(Bruce) The regression tests have been adapted and extensively modified for the - 6.1 release of Postgres. + 6.1 release of PostgreSQL. Three new data types (datetime, timespan, and circle) have been added to - the native set of Postgres types. Points, boxes, paths, and polygons + the native set of PostgreSQL types. Points, boxes, paths, and polygons have had their output formats made consistent across the data types. The polygon output in misc.out has only been spot-checked for correctness relative to the original regression output. - Postgres 6.1 introduces a new, alternate + PostgreSQL 6.1 introduces a new, alternate optimizer which uses genetic algorithms. These algorithms introduce a random behavior in the ordering of query results when the query contains multiple qualifiers or multiple @@ -3253,7 +3253,7 @@ DG-UX, Ultrix, Irix, AIX portability fixes A dump/restore is required for those wishing to migrate data from -previous releases of Postgres. +previous releases of PostgreSQL. diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index 6036a075c40..01a536e800d 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -1,4 +1,4 @@ - + The Rule System @@ -18,7 +18,7 @@ Production rule systems are conceptually simple, but there are many subtle points involved in actually using them. Some of these points and - the theoretical foundations of the Postgres + the theoretical foundations of the PostgreSQL rule system can be found in . @@ -26,7 +26,7 @@ Some other database systems define active database rules. These are usually stored procedures and triggers and are implemented - in Postgres as functions and triggers. + in PostgreSQL as functions and triggers. @@ -64,7 +64,7 @@ Now what is a query tree? It is an internal representation of an SQL statement where the single parts that built it are stored separately. These query trees are visible when starting - the Postgres backend with debug level 4 + the PostgreSQL backend with debug level 4 and typing queries into the interactive backend interface. The rule actions in the pg_rewrite system catalog are also stored as query trees. They are not formatted like the debug @@ -268,10 +268,10 @@ rulesand views -Implementation of Views in <ProductName>Postgres</ProductName> +Implementation of Views in <ProductName>PostgreSQL</ProductName> - Views in Postgres are implemented + Views in PostgreSQL are implemented using the rule system. In fact there is absolutely no difference between a @@ -289,7 +289,7 @@ because this is exactly what the CREATE VIEW command does internally. This has some side effects. One of them is that - the information about a view in the Postgres + the information about a view in the PostgreSQL system catalogs is exactly the same as it is for a table. So for the query parser, there is absolutely no difference between a table and a view. They are the same thing - relations. That is the @@ -785,7 +785,7 @@ SELECT t1.a, t2.b, t1.ctid FROM t1, t2 WHERE t1.a = t2.a; - Now another detail of Postgres enters the + Now another detail of PostgreSQL enters the stage. At this moment, table rows aren't overwritten and this is why ABORT TRANSACTION is fast. In an UPDATE, the new result row is inserted into the table (after stripping ctid) and in the tuple header of the row @@ -802,7 +802,7 @@ -The Power of Views in <ProductName>Postgres</ProductName> +The Power of Views in <ProductName>PostgreSQL</ProductName> The above demonstrates how the rule system incorporates @@ -826,7 +826,7 @@ Now the planner has to decide which is the best path to execute the query. The more information the planner has, the better this decision can be. And - the rule system as implemented in Postgres + the rule system as implemented in PostgreSQL ensures, that this is all information available about the query up to now. @@ -1604,7 +1604,7 @@ Merge Join - A final demonstration of the Postgres + A final demonstration of the PostgreSQL rule system and its power. There is a cute blonde that sells shoelaces. And what Al could never realize, she's not only cute, she's smart too - a little too smart. Thus, it @@ -1644,7 +1644,7 @@ Merge Join For the 1000 magenta shoelaces we must debt Al before we can throw 'em away, but that's another problem. The pink entry we delete. - To make it a little harder for Postgres, + To make it a little harder for PostgreSQL, we don't delete it directly. Instead we create one more view @@ -1708,7 +1708,7 @@ Merge Join Rules and Permissions - Due to rewriting of queries by the Postgres + Due to rewriting of queries by the PostgreSQL rule system, other tables/views than those used in the original query get accessed. Using update rules, this can include write access to tables. @@ -1718,7 +1718,7 @@ Merge Join Rewrite rules don't have a separate owner. The owner of a relation (table or view) is automatically the owner of the rewrite rules that are defined for it. - The Postgres rule system changes the + The PostgreSQL rule system changes the behavior of the default access control system. Relations that are used due to rules get checked against the permissions of the rule owner, not the user invoking the rule. @@ -1798,7 +1798,7 @@ Merge Join Many things that can be done using triggers can also be - implemented using the Postgres + implemented using the PostgreSQL rule system. What currently cannot be implemented by rules are some kinds of constraints. It is possible, to place a qualified rule that rewrites a query to NOTHING @@ -1971,7 +1971,7 @@ Merge Join Another situation is cases on UPDATE where it depends on the change of an attribute if an action should be performed or - not. In Postgres version 6.4, the + not. In PostgreSQL version 6.4, the attribute specification for rule events is disabled (it will have its comeback latest in 6.5, maybe earlier - stay tuned). So for now the only way to diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml index 81141607dfc..c694cfc7555 100644 --- a/doc/src/sgml/runtime.sgml +++ b/doc/src/sgml/runtime.sgml @@ -1,5 +1,5 @@ @@ -11,7 +11,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.96 2001/11/20 04:27:49 tgl - The Postgres user account + The <productname>PostgreSQL</productname> user account postgres user @@ -19,7 +19,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.96 2001/11/20 04:27:49 tgl As with any other server daemon that is connected to the world at - large, it is advisable to run Postgres under a separate user + large, it is advisable to run PostgreSQL under a separate user account. This user account should only own the data itself that is being managed by the server, and should not be shared with other daemons. (Thus, using the user nobody is a bad @@ -77,7 +77,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.96 2001/11/20 04:27:49 tgl > initdb -D /usr/local/pgsql/data Note that you must execute this command while being logged in to - the Postgres user account, which is described in the previous + the PostgreSQL user account, which is described in the previous section. @@ -97,7 +97,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.96 2001/11/20 04:27:49 tgl have the permission to do so (if you followed our advice and created an unprivileged account). In that case you should create the directory yourself (as root) and transfer ownership of it to the - Postgres user account. Here is how this might work: + PostgreSQL user account. Here is how this might work: root# mkdir /usr/local/pgsql/data root# chown postgres /usr/local/pgsql/data @@ -115,7 +115,7 @@ postgres> initdb -D /usr/local/pgsql/data Because the data directory contains all the data stored in the database it is essential that it be well secured from unauthorized access. initdb therefore revokes access - permissions from everyone but the Postgres user account. + permissions from everyone but the PostgreSQL user account. @@ -159,7 +159,7 @@ NOTICE: Initializing database with en_US collation order. > postmaster -D /usr/local/pgsql/data which will leave the server running in the foreground. This must - again be done while logged in to the Postgres user account. Without + again be done while logged in to the PostgreSQL user account. Without a , the server will try to use the data directory in the environment variable PGDATA; if neither of these works it will fail. @@ -221,7 +221,7 @@ pg_ctl start -l logfile /etc/rc.local or /etc/rc.d/rc.local which is almost certainly no bad place to put such a command. Whatever you do, the server - must be run by the Postgres user account + must be run by the PostgreSQL user account and not by root or any other user. Therefore you probably always want to form your command lines along the lines of su -c '...' postgres, for example: @@ -347,7 +347,7 @@ IpcMemoryCreate: shmget(key=5440001, size=83918612, 01600) failed: Invalid argum FATAL 1: ShmemCreate: cannot create region probably means that your kernel's limit on the size of shared - memory areas is smaller than the buffer area that Postgres is + memory areas is smaller than the buffer area that 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, @@ -367,7 +367,7 @@ IpcSemaphoreCreate: semget(key=5440026, num=16, 01600) failed: No space left on does not mean that you've run out of disk space; it means that your kernel's limit on the number of System V semaphores is smaller than the number - Postgres wants to create. As above, + PostgreSQL wants to create. As above, you may be able to work around the problem by starting the postmaster with a reduced number of backend processes ( switch), but you'll eventually want to @@ -574,7 +574,7 @@ env PGOPTIONS='-c geqo=off' psql Sets the optimizer's assumption about the effective size of the disk cache (that is, the portion of the kernel's disk cache that will be used for - Postgres data files). This is + PostgreSQL data files). This is measured in disk pages, which are normally 8 kB apiece. @@ -756,7 +756,7 @@ env PGOPTIONS='-c geqo=off' psql The KSQO algorithm used to be absolutely essential for queries with many OR'ed AND clauses, but in - Postgres 7.0 and later the standard + PostgreSQL 7.0 and later the standard planner handles these queries fairly successfully. Hence the default is OFF. @@ -800,9 +800,9 @@ env PGOPTIONS='-c geqo=off' psql you are experiencing strange problems or crashes you might want to turn this on, as it might expose programming mistakes. To use this option, the macro USE_ASSERT_CHECKING - must be defined when Postgres is built (see the configure option + must be defined when PostgreSQL is built (see the configure option --enable-cassert). Note that - DEBUG_ASSERTIONS defaults to ON if Postgres + DEBUG_ASSERTIONS defaults to ON if PostgreSQL has been built this way. @@ -957,7 +957,7 @@ env PGOPTIONS='-c geqo=off' psql SYSLOG (integer) - Postgres allows the use of + PostgreSQL allows the use of syslog for logging. If this option is set to 1, messages go both to syslog and the standard output. A setting of 2 sends output only to syslog. (Some @@ -967,7 +967,7 @@ env PGOPTIONS='-c geqo=off' psql To use syslog, the build of - Postgres must be configured with + PostgreSQL must be configured with the option. @@ -1121,8 +1121,8 @@ env PGOPTIONS='-c geqo=off' psql The value for dynamic_library_path has to be a colon-separated list of absolute directory names. If a directory name starts with the special value $libdir, the - compiled-in PostgreSQL package library directory, which is where the - modules provided by the PostgreSQL distribution are installed, + compiled-in PostgreSQL package library directory, which is where the + modules provided by the PostgreSQL distribution are installed, is substituted. (Use pg_config --pkglibdir to print the name of this directory.) An example value: @@ -1157,7 +1157,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir' FSYNC (boolean) - If this option is on, the Postgres backend + If this option is on, the PostgreSQL backend will use the fsync() system call in several places to make sure that updates are physically written to disk and do not hang around in the kernel buffer cache. This @@ -1168,7 +1168,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir' - However, this operation slows down Postgres, + However, this operation slows down PostgreSQL, because at all those points it has to block and wait for the operating system to flush the buffers. Without fsync, the operating system is @@ -1181,7 +1181,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir' This option is the subject of an eternal debate in the - Postgres user and developer communities. Some + PostgreSQL user and developer communities. Some always leave it off, some turn it off only for bulk loads, where there is a clear restart point if something goes wrong, some leave it on just to be on the safe side. Because it is @@ -1192,7 +1192,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir' It should be noted that the performance penalty from doing - fsyncs is considerably less in Postgres version + fsyncs is considerably less in PostgreSQL version 7.1 than it was in prior releases. If you previously suppressed fsyncs because of performance problems, you may wish to reconsider your choice. @@ -1766,7 +1766,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir' Managing Kernel Resources - A large Postgres installation can quickly hit + A large PostgreSQL installation can quickly hit various operating system resource limits. (On some systems, the factory defaults are so low that you don't even need a really large installation.) If you have encountered this kind of @@ -1787,11 +1787,11 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir' Shared memory and semaphores are collectively referred to as System V IPC (together with message queues, which are - not relevant for Postgres). Almost all modern + not relevant for PostgreSQL). Almost all modern operating systems provide these features, but not all of them have them turned on or sufficiently sized by default, especially systems with BSD heritage. (For the QNX and BeOS ports, - Postgres provides its own replacement + PostgreSQL provides its own replacement implementation of these facilities.) @@ -1799,11 +1799,11 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir' The complete lack of these facilities is usually manifested by an Illegal system call error upon postmaster start. In that case there's nothing left to do but to reconfigure your - kernel -- Postgres won't work without them. + kernel -- PostgreSQL won't work without them. - When Postgres exceeds one of the various hard + When PostgreSQL exceeds one of the various hard limits of the IPC resources then the postmaster will refuse to start up and should leave a marginally instructive error message about which problem was encountered and what needs to be done @@ -1917,7 +1917,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir' Less likely to cause problems is the minimum size for shared memory segments (SHMMIN), which should be at most - somewhere around 256 kB for Postgres (it is + somewhere around 256 kB for PostgreSQL (it is usually just 1). The maximum number of segments system-wide (SHMMNI) or per-process (SHMSEG) should not cause a problem unless your system has them set to zero. Some @@ -1926,7 +1926,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir' - Postgres uses one semaphore per allowed connection + PostgreSQL uses one semaphore per allowed connection ( - In the current version of Postgres there is no ability to + In the current version of PostgreSQL there is no ability to store prepared plans in the system catalog and fetch them from there for execution. This will be implemented in future versions. @@ -2557,7 +2557,7 @@ Returns a newly-allocated copy of the rel name. Memory Management -Postgres allocates memory within memory +PostgreSQL allocates memory within memory contexts, which provide a convenient method of managing allocations made in many different places that need to live for differing amounts of time. Destroying a context releases all the @@ -3745,7 +3745,7 @@ Passed plan Visibility of Data Changes -Postgres data changes visibility rule: during a query execution, data +PostgreSQL data changes visibility rule: during a query execution, data changes made by the query itself (via SQL-function, SPI-function, triggers) are invisible to the query scan. For example, in query diff --git a/doc/src/sgml/start.sgml b/doc/src/sgml/start.sgml index 2e6eddefb6f..bda58c4ef1f 100644 --- a/doc/src/sgml/start.sgml +++ b/doc/src/sgml/start.sgml @@ -1,5 +1,5 @@ @@ -169,7 +169,7 @@ CREATE DATABASE createdb: command not found - then PostgreSQL was not installed properly. Either it was not + then PostgreSQL was not installed properly. Either it was not installed at all or the search path was not set correctly. Try calling the command with an absolute path instead: @@ -392,7 +392,7 @@ mydb=# command shell. (For more internal commands, type \? at the psql prompt.) The full capabilities of psql are documented in the - Reference Manual. If PostgreSQL is + Reference Manual. If PostgreSQL is installed correctly you can also type man psql at the operating system shell prompt to see the documentation. In this tutorial we will not use these features explicitly, but you diff --git a/doc/src/sgml/syntax.sgml b/doc/src/sgml/syntax.sgml index c3e1ae59eae..fa221682e4c 100644 --- a/doc/src/sgml/syntax.sgml +++ b/doc/src/sgml/syntax.sgml @@ -1,5 +1,5 @@ @@ -174,7 +174,7 @@ UPDATE "my_table" SET "a" = 5; unquoted names are always folded to lower case. For example, the identifiers FOO, foo and "foo" are considered the same by - Postgres, but "Foo" + PostgreSQL, but "Foo" and "FOO" are different from these three and each other. @@ -201,7 +201,7 @@ UPDATE "my_table" SET "a" = 5; There are four kinds of implicitly typed - constants in Postgres: + constants in PostgreSQL: strings, bit strings, integers, and floating point numbers. Constants can also be specified with explicit types, which can enable more accurate representation and more efficient handling by @@ -227,7 +227,7 @@ UPDATE "my_table" SET "a" = 5; is a string'. SQL allows single quotes to be embedded in strings by typing two adjacent single quotes (e.g., 'Dianne''s horse'). In - Postgres single quotes may + PostgreSQL single quotes may alternatively be escaped with a backslash (\, e.g., 'Dianne\'s horse'). @@ -342,7 +342,7 @@ SELECT 'foo' 'bar'; Floating point constants are of type DOUBLE PRECISION. REAL can be specified explicitly by using SQL string notation or - Postgres type notation: + PostgreSQL type notation: REAL '1.23' -- string style @@ -483,7 +483,7 @@ CAST ( 'string' AS type ) For example, @- is an allowed operator name, but *- is not. This restriction allows - Postgres to parse SQL-compliant + PostgreSQL to parse SQL-compliant queries without requiring spaces between tokens. @@ -496,7 +496,7 @@ CAST ( 'string' AS type ) For example, if you have defined a left-unary operator named @, you cannot write X*@Y; you must write X* @Y to ensure that - Postgres reads it as two operator names + PostgreSQL reads it as two operator names not one. @@ -641,7 +641,7 @@ CAST ( 'string' AS type ) OID The object identifier (object ID) of a row. This is a serial number - that is automatically added by Postgres to all table rows (unless + that is automatically added by PostgreSQL to all table rows (unless the table was created WITHOUT OIDS, in which case this column is not present). @@ -734,7 +734,7 @@ CAST ( 'string' AS type ) a unique index on the OID column of each table for which the OID will be used. Never assume that OIDs are unique across tables; use the combination of tableoid and row OID if you need a database-wide - identifier. (Future releases of Postgres are likely to use a separate + identifier. (Future releases of PostgreSQL are likely to use a separate OID counter for each table, so that tableoid must be included to arrive at a globally unique identifier.) @@ -1052,7 +1052,7 @@ SELECT (5 !) - 6; :: left - Postgres-style typecast + PostgreSQL-style typecast diff --git a/doc/src/sgml/trigger.sgml b/doc/src/sgml/trigger.sgml index 2bca167378d..540ef0f71b3 100644 --- a/doc/src/sgml/trigger.sgml +++ b/doc/src/sgml/trigger.sgml @@ -2,7 +2,7 @@ Triggers - Postgres has various server-side function + PostgreSQL has various server-side function interfaces. Server-side functions can be written in SQL, PLPGSQL, TCL, or C. Trigger functions can be written in any of these languages except SQL. Note that STATEMENT-level trigger events are not @@ -189,7 +189,7 @@ CREATE TRIGGER trigger [ BEFORE | AFTER ] [ INSERT | The interface described here applies for - Postgres 7.1 and later. + PostgreSQL 7.1 and later. Earlier versions passed the TriggerData pointer in a global variable CurrentTriggerData. @@ -392,7 +392,7 @@ typedef struct Trigger Visibility of Data Changes - Postgres data changes visibility rule: during a query execution, data + PostgreSQL data changes visibility rule: during a query execution, data changes made by the query itself (via SQL-function, SPI-function, triggers) are invisible to the query scan. For example, in query diff --git a/doc/src/sgml/wal.sgml b/doc/src/sgml/wal.sgml index 4733786f95c..2b650e71d26 100644 --- a/doc/src/sgml/wal.sgml +++ b/doc/src/sgml/wal.sgml @@ -1,4 +1,4 @@ - + Write-Ahead Logging (<acronym>WAL</acronym>) @@ -339,7 +339,8 @@ The WAL_SYNC_METHOD parameter determines how - Postgres will ask the kernel to force WAL updates out to disk. + PostgreSQL will ask the kernel to force + WAL updates out to disk. All the options should be the same as far as reliability goes, but it's quite platform-specific which one will be the fastest. Note that this parameter is irrelevant if FSYNC diff --git a/doc/src/sgml/xaggr.sgml b/doc/src/sgml/xaggr.sgml index d3e6795eb83..c73a0e0d6a7 100644 --- a/doc/src/sgml/xaggr.sgml +++ b/doc/src/sgml/xaggr.sgml @@ -1,5 +1,5 @@ @@ -11,7 +11,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/xaggr.sgml,v 1.14 2001/09/13 15:55:23 peter - Aggregate functions in Postgres + Aggregate functions in PostgreSQL are expressed as state values and state transition functions. That is, an aggregate can be @@ -62,7 +62,7 @@ SELECT complex_sum(a) FROM test_complex; (In practice, we'd just name the aggregate sum, and rely on - Postgres to figure out which kind + PostgreSQL to figure out which kind of sum to apply to a complex column.) @@ -77,7 +77,7 @@ SELECT complex_sum(a) FROM test_complex; Sum and some other simple aggregates like Max and Min, it's sufficient to insert the first non-null input value into the state variable and then start applying the transition function - at the second non-null input value. Postgres + at the second non-null input value. PostgreSQL will do that automatically if the initial condition is NULL and the transition function is marked strict (i.e., not to be called for NULL inputs). diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml index 72500380425..1b3c86d3f03 100644 --- a/doc/src/sgml/xfunc.sgml +++ b/doc/src/sgml/xfunc.sgml @@ -1,5 +1,5 @@ @@ -23,7 +23,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.44 2001/11/18 21:28:00 tgl E Consequently, while it is possible to define a new function without defining a new type, the reverse is not true. We therefore describe how to add new functions - to Postgres before describing + to PostgreSQL before describing how to add new types. @@ -575,7 +575,8 @@ CREATE FUNCTION square_root(double precision) RETURNS double precision If the name starts with the string $libdir, - that part is replaced by the PostgreSQL package library directory + that part is replaced by the PostgreSQL package + library directory name, which is determined at build time.$libdir @@ -669,7 +670,8 @@ CREATE FUNCTION square_root(double precision) RETURNS double precision gives the C type required for - parameters in the C functions that will be loaded into Postgres. + parameters in the C functions that will be loaded into + PostgreSQL The Defined In column gives the header file that needs to be included to get the type definition. (The actual definition may be in a different file that is included by the @@ -853,11 +855,11 @@ CREATE FUNCTION square_root(double precision) RETURNS double precision - Internally, Postgres regards a + Internally, PostgreSQL regards a base type as a blob of memory. The user-defined functions that you define over a type in turn define the - way that Postgres can operate - on it. That is, Postgres will + way that PostgreSQL can operate + on it. That is, PostgreSQL will only store and retrieve the data from disk and use your user-defined functions to input, process, and output the data. Base types can have one of three internal formats: @@ -920,7 +922,7 @@ typedef struct Only pointers to such types can be used when passing - them in and out of Postgres functions. + them in and out of PostgreSQL functions. To return a value of such a type, allocate the right amount of memory with palloc(), fill in the allocated memory, and return a pointer to it. (Alternatively, you can return an input @@ -955,7 +957,7 @@ typedef struct { if it were declared the right length. (If this isn't a familiar trick to you, you may wish to spend some time with an introductory C programming textbook before delving deeper into - Postgres server programming.) + PostgreSQL server programming.) When manipulating variable-length types, we must be careful to allocate the correct amount of memory and set the length field correctly. @@ -1071,7 +1073,7 @@ concat_text(text *arg1, text *arg2) Supposing that the above code has been prepared in file funcs.c and compiled into a shared object, - we could define the functions to Postgres + we could define the functions to PostgreSQL with commands like this: @@ -1101,7 +1103,7 @@ CREATE FUNCTION concat_text(text, text) RETURNS text Here PGROOT stands for the full path to - the Postgres source tree. (Better style would + the PostgreSQL source tree. (Better style would be to use just 'funcs' in the AS clause, after having added PGROOT/tutorial to the search path. In any case, we may omit the system-specific @@ -1146,7 +1148,8 @@ PG_FUNCTION_INFO_V1(funcname); must appear in the same source file (conventionally it's written just before the function itself). This macro call is not needed - for internal-language functions, since Postgres currently + for internal-language functions, since + PostgreSQL currently assumes all internal functions are version-1. However, it is required for dynamically-loaded functions. @@ -1307,9 +1310,9 @@ concat_text(PG_FUNCTION_ARGS) null fields. In addition, composite types that are part of an inheritance hierarchy may have different fields than other members of the same inheritance hierarchy. - Therefore, Postgres provides + Therefore, PostgreSQL provides a procedural interface for accessing fields of composite types - from C. As Postgres processes + from C. As PostgreSQL processes a set of rows, each row will be passed into your function as an opaque structure of type TUPLE. Suppose we want to write a function to answer the query @@ -1363,7 +1366,7 @@ c_overpaid(PG_FUNCTION_ARGS) GetAttributeByName is the - Postgres system function that + PostgreSQL system function that returns attributes out of the current row. It has three arguments: the argument of type TupleTableSlot* passed into the function, the name of the desired attribute, and a @@ -1374,7 +1377,7 @@ c_overpaid(PG_FUNCTION_ARGS) - The following query lets Postgres + The following query lets PostgreSQL know about the c_overpaid function: @@ -1403,9 +1406,9 @@ LANGUAGE C; have a good understanding of C (including the use of pointers and the malloc memory manager) before trying to write C functions for - use with Postgres. While it may + use with PostgreSQL. While it may be possible to load functions written in languages other - than C into Postgres, + than C into PostgreSQL, this is often difficult (when it is possible at all) because other languages, such as FORTRAN and Pascal often do not follow the same @@ -1425,9 +1428,10 @@ LANGUAGE C; Use pg_config --includedir-serverpg_config to find - out where the PostgreSQL server header files are installed on + out where the PostgreSQL server header files are installed on your system (or the system that your users will be running - on). This option is new with PostgreSQL 7.2. For PostgreSQL + on). This option is new with PostgreSQL 7.2. + For PostgreSQL 7.1 you should use the option . (pg_config will exit with a non-zero status if it encounters an unknown option.) For releases prior to @@ -1440,7 +1444,7 @@ LANGUAGE C; When allocating memory, use the - Postgres routines + PostgreSQL routines palloc and pfree instead of the corresponding C library routines malloc and @@ -1465,7 +1469,7 @@ LANGUAGE C; - Most of the internal Postgres types + Most of the internal PostgreSQL types are declared in postgres.h, while the function manager interfaces (PG_FUNCTION_ARGS, etc.) are in fmgr.h, so you will need to @@ -1492,7 +1496,7 @@ LANGUAGE C; Compiling and linking your object code so that it can be dynamically loaded into - Postgres + PostgreSQL always requires special flags. See for a detailed explanation of how to do it for diff --git a/doc/src/sgml/xindex.sgml b/doc/src/sgml/xindex.sgml index 66b39eb0bf2..453f86ceae1 100644 --- a/doc/src/sgml/xindex.sgml +++ b/doc/src/sgml/xindex.sgml @@ -1,6 +1,6 @@ @@ -17,7 +17,7 @@ Postgres documentation Look back at . The right half shows the catalogs that we must modify in order to tell - Postgres how to use a user-defined type and/or + PostgreSQL how to use a user-defined type and/or user-defined operators with an index (i.e., pg_am, pg_amop, pg_amproc, pg_operator and pg_opclass). Unfortunately, there is no simple command to do this. We will demonstrate @@ -29,7 +29,7 @@ Postgres documentation The pg_am table contains one row for every index access method. Support for the heap access method is built into - Postgres, but every other access method is + PostgreSQL, but every other access method is described in pg_am. The schema is @@ -121,18 +121,18 @@ SELECT oid FROM pg_am WHERE amname = 'btree'; The amstrategies column exists to standardize comparisons across data types. For example, B-trees impose a strict ordering on keys, lesser to greater. Since - Postgres allows the user to define operators, - Postgres cannot look at the name of an operator + PostgreSQL allows the user to define operators, + PostgreSQL cannot look at the name of an operator (e.g., > or <) and tell what kind of comparison it is. In fact, some access methods don't impose any ordering at all. For example, R-trees express a rectangle-containment relationship, whereas a hashed data structure expresses only bitwise similarity based - on the value of a hash function. Postgres + on the value of a hash function. PostgreSQL needs some consistent way of taking a qualification in your query, looking at the operator and then deciding if a usable index exists. This - implies that Postgres needs to know, for + implies that PostgreSQL needs to know, for example, that the <= and > operators partition a - B-tree. Postgres + B-tree. PostgreSQL uses strategies to express these relationships between operators and the way they can be used to scan indexes. @@ -208,7 +208,7 @@ SELECT oid FROM pg_am WHERE amname = 'btree'; In order to manage diverse support routines consistently across all - Postgres access methods, + PostgreSQL access methods, pg_am includes a column called amsupport. This column records the number of support routines used by an access method. For B-trees, @@ -337,7 +337,7 @@ SELECT oid, * - We make the function known to Postgres like this: + We make the function known to PostgreSQL like this: CREATE FUNCTION complex_abs_eq(complex, complex) RETURNS bool @@ -362,7 +362,7 @@ CREATE FUNCTION complex_abs_eq(complex, complex) - Second, although Postgres can cope with operators having + Second, although PostgreSQL can cope with operators having the same name as long as they have different input data types, C can only cope with one global routine having a given name, period. So we shouldn't name the C function something simple like abs_eq. @@ -371,11 +371,11 @@ CREATE FUNCTION complex_abs_eq(complex, complex) - Third, we could have made the Postgres name of the function - abs_eq, relying on Postgres to distinguish it - by input data types from any other Postgres function of the same name. + Third, we could have made the PostgreSQL name of the function + abs_eq, relying on PostgreSQL to distinguish it + by input data types from any other PostgreSQL function of the same name. To keep the example simple, we make the function have the same names - at the C level and Postgres level. + at the C level and PostgreSQL level. @@ -484,7 +484,7 @@ CREATE OPERATOR = ( pg_amproc table, keyed by the operator class oid and the support routine number. First, we need to register the function in - Postgres (recall that we put the + PostgreSQL (recall that we put the C code that implements this routine in the bottom of the file in which we implemented the operator routines): diff --git a/doc/src/sgml/xoper.sgml b/doc/src/sgml/xoper.sgml index e2358dfd635..673c7702b1b 100644 --- a/doc/src/sgml/xoper.sgml +++ b/doc/src/sgml/xoper.sgml @@ -1,12 +1,12 @@ Extending <Acronym>SQL</Acronym>: Operators - Postgres supports left unary, + PostgreSQL supports left unary, right unary and binary operators. Operators can be overloaded; that is, the same operator name can be used for different operators @@ -87,7 +87,7 @@ SELECT (a + b) AS c FROM test_complex; - A Postgres operator definition can include + A PostgreSQL operator definition can include several optional clauses that tell the system useful things about how the operator behaves. These clauses should be provided whenever appropriate, because they can make for considerable speedups in execution @@ -101,7 +101,7 @@ SELECT (a + b) AS c FROM test_complex; Additional optimization clauses might be added in future versions of - Postgres. The ones described here are all + PostgreSQL. The ones described here are all the ones that release 6.5 understands. @@ -121,7 +121,7 @@ SELECT (a + b) AS c FROM test_complex; The left argument type of a commuted operator is the same as the right argument type of its commutator, and vice versa. So the name of - the commutator operator is all that Postgres + the commutator operator is all that PostgreSQL needs to be given to look up the commutator, and that's all that need be provided in the COMMUTATOR clause. @@ -138,7 +138,7 @@ SELECT (a + b) AS c FROM test_complex; One way is to omit the COMMUTATOR clause in the first operator that you define, and then provide one in the second operator's definition. - Since Postgres knows that commutative + Since PostgreSQL knows that commutative operators come in pairs, when it sees the second definition it will automatically go back and fill in the missing COMMUTATOR clause in the first definition. @@ -148,18 +148,18 @@ SELECT (a + b) AS c FROM test_complex; The other, more straightforward way is just to include COMMUTATOR clauses - in both definitions. When Postgres processes + in both definitions. When PostgreSQL processes the first definition and realizes that COMMUTATOR refers to a non-existent operator, the system will make a dummy entry for that operator in the system's pg_operator table. This dummy entry will have valid data only for the operator name, left and right argument types, and result type, - since that's all that Postgres can deduce + since that's all that PostgreSQL can deduce at this point. The first operator's catalog entry will link to this dummy entry. Later, when you define the second operator, the system updates the dummy entry with the additional information from the second definition. If you try to use the dummy operator before it's been filled in, you'll just get an error message. (Note: this procedure did not work - reliably in Postgres versions before 6.5, + reliably in PostgreSQL versions before 6.5, but it is now the recommended way to do things.) diff --git a/doc/src/sgml/xplang.sgml b/doc/src/sgml/xplang.sgml index bcb7dd01809..ce8c0d0ac79 100644 --- a/doc/src/sgml/xplang.sgml +++ b/doc/src/sgml/xplang.sgml @@ -1,12 +1,12 @@ Procedural Languages - Postgres allows users to add new + PostgreSQL allows users to add new programming languages to be available for writing functions and procedures. These are called procedural languages (PL). In the case of a function or trigger @@ -16,7 +16,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/xplang.sgml,v 1.15 2001/09/10 21:58:47 pete the details of the language. The handler could either do all the work of parsing, syntax analysis, execution, etc. itself, or it could serve as glue between - Postgres and an existing implementation + PostgreSQL and an existing implementation of a programming language. The handler itself is a special programming language function compiled into a shared object and loaded on demand. @@ -26,7 +26,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/xplang.sgml,v 1.15 2001/09/10 21:58:47 pete Writing a handler for a new procedural language is outside the scope of this manual, although some information is provided in the CREATE LANGUAGE reference page. Several procedural languages are - available in the standard Postgres distribution. + available in the standard PostgreSQL distribution. @@ -110,7 +110,7 @@ CREATE TRUSTED PROCEDURAL LANGUAGE - In a default Postgres installation, the + In a default PostgreSQL installation, the handler for the PL/pgSQL language is built and installed into the library directory. If Tcl/Tk support is configured in, the handlers for PL/Tcl and PL/TclU are also built and installed in diff --git a/doc/src/sgml/xtypes.sgml b/doc/src/sgml/xtypes.sgml index f4a8c4c4a99..3ab3dd7e790 100644 --- a/doc/src/sgml/xtypes.sgml +++ b/doc/src/sgml/xtypes.sgml @@ -8,7 +8,7 @@ As previously mentioned, there are two kinds of types - in Postgres: base types (defined in a programming language) + in PostgreSQL: base types (defined in a programming language) and composite types. Examples in this section up to interfacing indexes can be found in complex.sql and complex.c. Composite examples @@ -127,10 +127,10 @@ CREATE TYPE complex ( - As discussed earlier, Postgres fully supports arrays of - base types. Additionally, Postgres supports arrays of + As discussed earlier, PostgreSQL fully supports arrays of + base types. Additionally, PostgreSQL supports arrays of user-defined types as well. When you define a type, - Postgres automatically provides support for arrays of + PostgreSQL automatically provides support for arrays of that type. For historical reasons, the array type has the same name as the user-defined type with the underscore character _ prepended. diff --git a/doc/src/sgml/y2k.sgml b/doc/src/sgml/y2k.sgml index 6b6e1f8725c..a41f1ad6aa1 100644 --- a/doc/src/sgml/y2k.sgml +++ b/doc/src/sgml/y2k.sgml @@ -1,5 +1,5 @@ @@ -26,9 +26,9 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/y2k.sgml,v 1.12 2001/11/14 20:40:33 m The author of this statement, a volunteer on the - Postgres + PostgreSQL support team since November, 1996, is not aware of - any problems in the Postgres code base related + any problems in the PostgreSQL code base related to time transitions around Jan 1, 2000 (Y2K). @@ -38,7 +38,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/y2k.sgml,v 1.12 2001/11/14 20:40:33 m The author of this statement is not aware of any reports of Y2K problems uncovered in regression testing or in other field use of recent or current versions - of Postgres. We might have expected + of PostgreSQL. We might have expected to hear about problems if they existed, given the installed base and the active participation of users on the support mailing lists. @@ -47,7 +47,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/y2k.sgml,v 1.12 2001/11/14 20:40:33 m To the best of the author's knowledge, the - assumptions Postgres makes about dates specified with a two-digit year + assumptions PostgreSQL + makes about dates specified with a two-digit year are documented in the current User's Guide in the chapter on data types. For two-digit years, the significant transition year is 1970, not 2000; @@ -60,7 +61,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/y2k.sgml,v 1.12 2001/11/14 20:40:33 m Any Y2K problems in the underlying OS related to obtaining the current time may propagate into apparent Y2K problems in - Postgres. + PostgreSQL.