Skip to content

P
Postgres FD Implementation
Commit a134ee33 authored by Bruce Momjian's avatar Bruce Momjian
Browse files
Options

Update documentation on may/can/might: 

Standard English uses "may", "can", and "might" in different ways:

        may - permission, "You may borrow my rake."

        can - ability, "I can lift that log."

        might - possibility, "It might rain today."

Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice.  Similarly, "It may crash" is better stated, "It might crash".

Also update two error messages mentioned in the documenation to match.
parent 67a1ae9f
Expand all Hide whitespace changes
Inline Side-by-side
Showing with 729 additions and 731 deletions
doc/src/sgml/advanced.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/advanced.sgml,v 1.52 2006/10/21 23:12:57 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/advanced.sgml,v 1.53 2007/01/31 20:56:16 momjian Exp $ -->
<chapter id="tutorial-advanced">
<title>Advanced Features</title>
......@@ -57,7 +57,7 @@ SELECT * FROM myview;
<para>
Making liberal use of views is a key aspect of good SQL database
design. Views allow you to encapsulate the details of the
structure of your tables, which may change as your application
structure of your tables, which might change as your application
evolves, behind consistent interfaces.
</para>
......@@ -250,7 +250,7 @@ COMMIT;
<note>
<para>
Some client libraries issue <command>BEGIN</> and <command>COMMIT</>
commands automatically, so that you may get the effect of transaction
commands automatically, so that you might get the effect of transaction
blocks without asking. Check the documentation for the interface
you are using.
</para>
......
doc/src/sgml/arch-dev.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/arch-dev.sgml,v 2.28 2006/09/16 00:30:11 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/arch-dev.sgml,v 2.29 2007/01/31 20:56:16 momjian Exp $ -->
<chapter id="overview">
<title>Overview of PostgreSQL Internals</title>
......@@ -272,7 +272,7 @@
similar to the raw parse tree in most places, but it has many differences
in detail. For example, a <structname>FuncCall</> node in the
parse tree represents something that looks syntactically like a function
call. This may be transformed to either a <structname>FuncExpr</>
call. This might be transformed to either a <structname>FuncExpr</>
or <structname>Aggref</> node depending on whether the referenced
name turns out to be an ordinary function or an aggregate function.
Also, information about the actual data types of columns and expression
......@@ -342,7 +342,7 @@
<note>
<para>
In some situations, examining each possible way in which a query
may be executed would take an excessive amount of time and memory
can be executed would take an excessive amount of time and memory
space. In particular, this occurs when executing queries
involving large numbers of join operations. In order to determine
a reasonable (not optimal) query plan in a reasonable amount of
......@@ -414,7 +414,7 @@
scanned in parallel, and matching rows are combined to form
join rows. This kind of join is more
attractive because each relation has to be scanned only once.
The required sorting may be achieved either by an explicit sort
The required sorting might be achieved either by an explicit sort
step, or by scanning the relation in the proper order using an
index on the join key.
</para>
......@@ -502,7 +502,7 @@
</para>
<para>
Complex queries may involve many levels of plan nodes, but the general
Complex queries can involve many levels of plan nodes, but the general
approach is the same: each node computes and returns its next output
row each time it is called. Each node is also responsible for applying
any selection or projection expressions that were assigned to it by
......@@ -518,7 +518,7 @@
into the target table specified for the <command>INSERT</>. (A simple
<command>INSERT ... VALUES</> command creates a trivial plan tree
consisting of a single <literal>Result</> node, which computes just one
result row. But <command>INSERT ... SELECT</> may demand the full power
result row. But <command>INSERT ... SELECT</> can demand the full power
of the executor mechanism.) For <command>UPDATE</>, the planner arranges
that each computed row includes all the updated column values, plus
the <firstterm>TID</> (tuple ID, or row ID) of the original target row;
......
doc/src/sgml/array.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/array.sgml,v 1.54 2007/01/31 04:12:01 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/array.sgml,v 1.55 2007/01/31 20:56:16 momjian Exp $ -->
<sect1 id="arrays">
<title>Arrays</title>
......@@ -63,7 +63,7 @@ CREATE TABLE tictactoe (
</para>
<para>
An alternative syntax, which conforms to the SQL standard, may
An alternative syntax, which conforms to the SQL standard, can
be used for one-dimensional arrays.
<structfield>pay_by_quarter</structfield> could have been defined
as:
......@@ -88,7 +88,7 @@ CREATE TABLE tictactoe (
To write an array value as a literal constant, enclose the element
values within curly braces and separate them by commas. (If you
know C, this is not unlike the C syntax for initializing
structures.) You may put double quotes around any element value,
structures.) You can put double quotes around any element value,
and must do so if it contains commas or curly braces. (More
details appear below.) Thus, the general format of an array
constant is the following:
......@@ -155,7 +155,7 @@ SELECT * FROM sal_emp;
</para>
<para>
The <literal>ARRAY</> constructor syntax may also be used:
The <literal>ARRAY</> constructor syntax can also be used:
<programlisting>
INSERT INTO sal_emp
VALUES ('Bill',
......@@ -333,7 +333,7 @@ UPDATE sal_emp SET pay_by_quarter = ARRAY[25000,25000,27000,27000]
WHERE name = 'Carol';
</programlisting>
An array may also be updated at a single element:
An array can also be updated at a single element:
<programlisting>
UPDATE sal_emp SET pay_by_quarter[4] = 15000
......@@ -453,7 +453,7 @@ SELECT array_dims(ARRAY[1,2] || ARRAY[[3,4],[5,6]]);
Note that the concatenation operator discussed above is preferred over
direct use of these functions. In fact, the functions exist primarily for use
in implementing the concatenation operator. However, they may be directly
in implementing the concatenation operator. However, they might be directly
useful in the creation of user-defined aggregates. Some examples:
<programlisting>
......@@ -525,7 +525,7 @@ SELECT * FROM sal_emp WHERE 10000 = ALL (pay_by_quarter);
<tip>
<para>
Arrays are not sets; searching for specific array elements
may be a sign of database misdesign. Consider
can be a sign of database misdesign. Consider
using a separate table with a row for each item that would be an
array element. This will be easier to search, and is likely to
scale up better to large numbers of elements.
......@@ -592,7 +592,7 @@ SELECT f1[1][-2][3] AS e1, f1[1][-1][5] AS e2
or backslashes disables this and allows the literal string value
<quote>NULL</> to be entered. Also, for backwards compatibility with
pre-8.2 versions of <productname>PostgreSQL</>, the <xref
linkend="guc-array-nulls"> configuration parameter may be turned
linkend="guc-array-nulls"> configuration parameter might be turned
<literal>off</> to suppress recognition of <literal>NULL</> as a NULL.
</para>
......@@ -611,8 +611,8 @@ SELECT f1[1][-2][3] AS e1, f1[1][-1][5] AS e2
</para>
<para>
You may write whitespace before a left brace or after a right
brace. You may also write whitespace before or after any individual item
You can write whitespace before a left brace or after a right
brace. You can also write whitespace before or after any individual item
string. In all of these cases the whitespace will be ignored. However,
whitespace within double-quoted elements, or surrounded on both sides by
non-whitespace characters of an element, is not ignored.
......
doc/src/sgml/backup.sgml
View file @ a134ee33
This diff is collapsed.
doc/src/sgml/bki.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/bki.sgml,v 1.19 2006/09/16 00:30:11 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/bki.sgml,v 1.20 2007/01/31 20:56:16 momjian Exp $ -->
<chapter id="bki">
<title><acronym>BKI</acronym> Backend Interface</title>
......@@ -29,7 +29,7 @@
</para>
<para>
Related information may be found in the documentation for
Related information can be found in the documentation for
<application>initdb</application>.
</para>
......
doc/src/sgml/catalogs.sgml
View file @ a134ee33
This diff is collapsed.
doc/src/sgml/charset.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/charset.sgml,v 2.80 2007/01/09 22:22:55 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/charset.sgml,v 2.81 2007/01/31 20:56:16 momjian Exp $ -->
<chapter id="charset">
<title>Localization</>
......@@ -155,7 +155,7 @@ initdb --locale=sv_SE
environment variables seen by the server, not by the environment
of any client. Therefore, be careful to configure the correct locale settings
before starting the server. A consequence of this is that if
client and server are set up in different locales, messages may
client and server are set up in different locales, messages might
appear in different languages depending on where they originated.
</para>
......@@ -252,7 +252,7 @@ initdb --locale=sv_SE
If locale support doesn't work in spite of the explanation above,
check that the locale support in your operating system is
correctly configured. To check what locales are installed on your
system, you may use the command <literal>locale -a</literal> if
system, you can use the command <literal>locale -a</literal> if
your operating system provides it.
</para>
......
doc/src/sgml/client-auth.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.96 2006/11/23 05:39:17 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.97 2007/01/31 20:56:16 momjian Exp $ -->
<chapter id="client-authentication">
<title>Client Authentication</title>
......@@ -48,7 +48,7 @@
runs. If all the users of a particular server also have accounts on
the server's machine, it makes sense to assign database user names
that match their operating system user names. However, a server that
accepts remote connections may have many database users who have no local operating system
accepts remote connections might have many database users who have no local operating system
account, and in such cases there need be no connection between
database user names and OS user names.
</para>
......@@ -94,7 +94,7 @@
</para>
<para>
A record may have one of the seven formats
A record can have one of the seven formats
<synopsis>
local <replaceable>database</replaceable> <replaceable>user</replaceable> <replaceable>auth-method</replaceable> <optional><replaceable>auth-option</replaceable></optional>
host <replaceable>database</replaceable> <replaceable>user</replaceable> <replaceable>CIDR-address</replaceable> <replaceable>auth-method</replaceable> <optional><replaceable>auth-option</replaceable></optional>
......@@ -256,7 +256,7 @@ hostnossl <replaceable>database</replaceable> <replaceable>user</replaceable>
<term><replaceable>IP-mask</replaceable></term>
<listitem>
<para>
These fields may be used as an alternative to the
These fields can be used as an alternative to the
<replaceable>CIDR-address</replaceable> notation. Instead of
specifying the mask length, the actual mask is specified in a
separate column. For example, <literal>255.0.0.0</> represents an IPv4
......@@ -517,7 +517,7 @@ host all all 192.168.0.0/16 ident omicron
# If these are the only three lines for local connections, they will
# allow local users to connect only to their own databases (databases
# with the same name as their database user name) except for administrators
# and members of role "support", who may connect to all databases. The file
# and members of role "support", who can connect to all databases. The file
# $PGDATA/admins contains a list of names of administrators. Passwords
# are required in all cases.
#
......@@ -559,7 +559,7 @@ local db1,db2,@demodbs all md5
<literal>trust</> authentication is appropriate and very
convenient for local connections on a single-user workstation. It
is usually <emphasis>not</> appropriate by itself on a multiuser
machine. However, you may be able to use <literal>trust</> even
machine. However, you might be able to use <literal>trust</> even
on a multiuser machine, if you restrict access to the server's
Unix-domain socket file using file-system permissions. To do this, set the
<varname>unix_socket_permissions</varname> (and possibly
......@@ -679,7 +679,7 @@ local db1,db2,@demodbs all md5
<literal>./configure --with-krb-srvnam=whatever</>. In most environments,
this parameter never needs to be changed. However, to support multiple
<productname>PostgreSQL</> installations on the same host it is necessary.
Some Kerberos implementations may also require a different service name,
Some Kerberos implementations might also require a different service name,
such as Microsoft Active Directory which requires the service name
to be in uppercase (<literal>POSTGRES</literal>).
</para>
......@@ -865,7 +865,7 @@ local db1,db2,@demodbs all md5
as which database user. The same <replaceable>map-name</> can be
used repeatedly to specify more user-mappings within a single map.
There is no restriction regarding how many database users a given
operating system user may correspond to, nor vice versa.
operating system user can correspond to, nor vice versa.
</para>
<para>
......@@ -941,7 +941,7 @@ ldap://ldap.example.net/dc=example,dc=net;EXAMPLE\
will encrypt only the connection between the PostgreSQL server
and the LDAP server. The connection between the client and the
PostgreSQL server is not affected by this setting. To make use of
TLS encryption, you may need to configure the LDAP library prior
TLS encryption, you might need to configure the LDAP library prior
to configuring PostgreSQL. Note that encrypted LDAP is available only
if the platform's LDAP library supports it.
</para>
......@@ -1030,12 +1030,12 @@ FATAL: database "testdb" does not exist
</programlisting>
The database you are trying to connect to does not exist. Note that
if you do not specify a database name, it defaults to the database
user name, which may or may not be the right thing.
user name, which might or might not be the right thing.
</para>
<tip>
<para>
The server log may contain more information about an
The server log might contain more information about an
authentication failure than is reported to the client. If you are
confused about the reason for a failure, check the log.
</para>
......
doc/src/sgml/config.sgml
View file @ a134ee33
This diff is collapsed.
doc/src/sgml/cvs.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/cvs.sgml,v 1.39 2006/11/17 05:29:46 neilc Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/cvs.sgml,v 1.40 2007/01/31 20:56:16 momjian Exp $ -->
<appendix id="cvs">
<appendixinfo>
......@@ -88,7 +88,7 @@ cvs -z3 -d :pserver:anoncvs@anoncvs.postgresql.org:/projects/cvsroot co -P pgsql
<note>
<para>
If you have a fast link to the Internet, you may not need
If you have a fast link to the Internet, you might not need
<option>-z3</option>, which instructs
<productname>CVS</productname> to use <command>gzip</command> compression for transferred data. But
on a modem-speed link, it's a very substantial win.
......
doc/src/sgml/datatype.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.188 2007/01/30 22:29:22 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.189 2007/01/31 20:56:16 momjian Exp $ -->
<chapter id="datatype">
<title id="datatype-title">Data Types</title>
......@@ -14,7 +14,7 @@
<para>
<productname>PostgreSQL</productname> has a rich set of native data
types available to users. Users may add new types to
types available to users. Users can add new types to
<productname>PostgreSQL</productname> using the <xref
linkend="sql-createtype" endterm="sql-createtype-title"> command.
</para>
......@@ -267,7 +267,7 @@
paths, or have several possibilities for formats, such as the date
and time types.
Some of the input and output functions are not invertible. That is,
the result of an output function may lose accuracy when compared to
the result of an output function might lose accuracy when compared to
the original input.
</para>
......@@ -416,7 +416,7 @@
</para>
<para>
The <type>bigint</type> type may not function correctly on all
The <type>bigint</type> type might not function correctly on all
platforms, since it relies on compiler support for eight-byte
integers. On a machine without such support, <type>bigint</type>
acts the same as <type>integer</type> (but still takes up eight
......@@ -597,7 +597,7 @@ NUMERIC
<para>
Inexact means that some values cannot be converted exactly to the
internal format and are stored as approximations, so that storing
and printing back out a value may show slight discrepancies.
and printing back out a value might show slight discrepancies.
Managing these errors and how they propagate through calculations
is the subject of an entire branch of mathematics and computer
science and will not be discussed further here, except for the
......@@ -621,7 +621,7 @@ NUMERIC
<listitem>
<para>
Comparing two floating-point values for equality may or may
Comparing two floating-point values for equality might or might
not work as expected.
</para>
</listitem>
......@@ -633,7 +633,7 @@ NUMERIC
1E-37 to 1E+37 with a precision of at least 6 decimal digits. The
<type>double precision</type> type typically has a range of around
1E-307 to 1E+308 with a precision of at least 15 digits. Values that
are too large or too small will cause an error. Rounding may
are too large or too small will cause an error. Rounding might
take place if the precision of an input number is too high.
Numbers too close to zero that are not representable as distinct
from zero will cause an underflow error.
......@@ -698,7 +698,7 @@ NUMERIC
digits. The assumption that <type>real</type> and
<type>double precision</type> have exactly 24 and 53 bits in the
mantissa respectively is correct for IEEE-standard floating point
implementations. On non-IEEE platforms it may be off a little, but
implementations. On non-IEEE platforms it might be off a little, but
for simplicity the same ranges of <replaceable>p</replaceable> are used
on all platforms.
</para>
......@@ -978,7 +978,7 @@ ALTER SEQUENCE <replaceable class="parameter">tablename</replaceable>_<replaceab
The storage requirement for data of these types is 4 bytes plus the
actual string, and in case of <type>character</type> plus the
padding. Long strings are compressed by the system automatically, so
the physical requirement on disk may be less. Long values are also
the physical requirement on disk might 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
......@@ -1060,7 +1060,7 @@ SELECT b, char_length(b) FROM test2;
terminator) but should be referenced using the constant
<symbol>NAMEDATALEN</symbol>. The length is set at compile time (and
is therefore adjustable for special uses); the default maximum
length may change in a future release. The type <type>"char"</type>
length might change in a future release. The type <type>"char"</type>
(note the quotes) is different from <type>char(1)</type> in that it
only uses one byte of storage. It is internally used in the system
catalogs as a poor-man's enumeration type.
......@@ -1293,8 +1293,8 @@ SELECT b, char_length(b) FROM test2;
<para>
Depending on the front end to <productname>PostgreSQL</> you use,
you may have additional work to do in terms of escaping and
unescaping <type>bytea</type> strings. For example, you may also
you might have additional work to do in terms of escaping and
unescaping <type>bytea</type> strings. For example, you might also
have to escape line feeds and carriage returns if your interface
automatically translates these.
</para>
......@@ -1436,7 +1436,7 @@ SELECT b, char_length(b) FROM test2;
<para>
When <type>timestamp</> values are stored as double precision floating-point
numbers (currently the default), the effective limit of precision
may be less than 6. <type>timestamp</type> values are stored as seconds
might be less than 6. <type>timestamp</type> values are stored as seconds
before or after midnight 2000-01-01. Microsecond precision is achieved for
dates within a few years of 2000-01-01, but the precision degrades for
dates further away. When <type>timestamp</type> values are stored as
......@@ -2166,7 +2166,7 @@ January 8 04:05:06 1999 PST
<type>time</type> type can.
Time zones in the real world have little meaning unless
associated with a date as well as a time,
since the offset may vary through the year with daylight-saving
since the offset can vary through the year with daylight-saving
time boundaries.
</para>
</listitem>
......@@ -2220,7 +2220,7 @@ January 8 04:05:06 1999 PST
<para>
A time zone abbreviation, for example <literal>PST</>. Such a
specification merely defines a particular offset from UTC, in
contrast to full time zone names which may imply a set of daylight
contrast to full time zone names which might imply a set of daylight
savings transition-date rules as well. The recognized abbreviations
are listed in the <literal>pg_timezone_abbrevs</> view (see <xref
linkend="view-pg-timezone-abbrevs">). You cannot set the
......@@ -3374,14 +3374,14 @@ SELECT * FROM pg_attribute
</table>
<para>
Functions coded in C (whether built-in or dynamically loaded) may be
Functions coded in C (whether built-in or dynamically loaded) can be
declared to accept or return any of these pseudo data types. It is up to
the function author to ensure that the function will behave safely
when a pseudo-type is used as an argument type.
</para>
<para>
Functions coded in procedural languages may use pseudo-types only as
Functions coded in procedural languages can use pseudo-types only as
allowed by their implementation languages. At present the procedural
languages all forbid use of a pseudo-type as argument type, and allow
only <type>void</> and <type>record</> as a result type (plus
......
doc/src/sgml/datetime.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/datetime.sgml,v 2.55 2006/10/17 21:03:20 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/datetime.sgml,v 2.56 2007/01/31 20:56:16 momjian Exp $ -->
<appendix id="datetime-appendix">
<title>Date/Time Support</title>
......@@ -7,7 +7,7 @@
<productname>PostgreSQL</productname> uses an internal heuristic
parser for all date/time input support. Dates and times are input as
strings, and are broken up into distinct fields with a preliminary
determination of what kind of information may be in the
determination of what kind of information can be in the
field. Each field is interpreted and either assigned a numeric
value, ignored, or rejected.
The parser contains internal lookup tables for all textual fields,
......@@ -46,7 +46,7 @@
<para>
If the numeric token contains a dash (<literal>-</>), slash
(<literal>/</>), or two or more dots (<literal>.</>), this is
a date string which may have a text month. If a date token has
a date string which might have a text month. If a date token has
already been seen, it is instead interpreted as a time zone
name (e.g., <literal>America/New_York</>).
</para>
......@@ -166,7 +166,7 @@
<tip>
<para>
Gregorian years AD 1-99 may be entered by using 4 digits with leading
Gregorian years AD 1-99 can be entered by using 4 digits with leading
zeros (e.g., <literal>0099</> is AD 99).
</para>
</tip>
......@@ -382,7 +382,7 @@
</para>
<para>
A timezone abbreviation file may contain blank lines and comments
A timezone abbreviation file can contain blank lines and comments
beginning with <literal>#</>. Non-comment lines must have one of
these formats:
......@@ -413,7 +413,7 @@
<para>
The <literal>@OVERRIDE</> syntax indicates that subsequent entries in the
file may override previous entries (i.e., entries obtained from included
file can override previous entries (i.e., entries obtained from included
files). Without this, conflicting definitions of the same timezone
abbreviation are considered an error.
</para>
......
doc/src/sgml/ddl.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.71 2006/12/30 20:31:11 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.72 2007/01/31 20:56:16 momjian Exp $ -->
<chapter id="ddl">
<title>Data Definition</title>
......@@ -203,10 +203,10 @@ CREATE TABLE products (
</para>
<para>
The default value may be an expression, which will be
The default value can be an expression, which will be
evaluated whenever the default value is inserted
(<emphasis>not</emphasis> when the table is created). A common example
is that a <type>timestamp</type> column may have a default of <literal>now()</>,
is that a <type>timestamp</type> column can have a default of <literal>now()</>,
so that it gets set to the time of row insertion. Another common
example is generating a <quote>serial number</> for each row.
In <productname>PostgreSQL</productname> this is typically done by
......@@ -457,7 +457,7 @@ CREATE TABLE products (
The <literal>NOT NULL</literal> constraint has an inverse: the
<literal>NULL</literal> constraint. This does not mean that the
column must be null, which would surely be useless. Instead, this
simply selects the default behavior that the column may be null.
simply selects the default behavior that the column might be null.
The <literal>NULL</literal> constraint is not present in the SQL
standard and should not be used in portable applications. (It was
only added to <productname>PostgreSQL</productname> to be
......@@ -558,7 +558,7 @@ CREATE TABLE products (
unique constraint it is possible to store duplicate
rows that contain a null value in at least one of the constrained
columns. This behavior conforms to the SQL standard, but we have
heard that other SQL databases may not follow this rule. So be
heard that other SQL databases might not follow this rule. So be
careful when developing applications that are intended to be
portable.
</para>
......@@ -1004,7 +1004,7 @@ CREATE TABLE order_items (
(Of course, this is only possible if the table contains fewer
than 2<superscript>32</> (4 billion) rows, and in practice the
table size had better be much less than that, or performance
may suffer.)
might suffer.)
</para>
</listitem>
<listitem>
......@@ -1289,7 +1289,7 @@ ALTER TABLE products ALTER COLUMN price TYPE numeric(10,2);
<para>
<productname>PostgreSQL</> will attempt to convert the column's
default value (if any) to the new type, as well as any constraints
that involve the column. But these conversions may fail, or may
that involve the column. But these conversions might fail, or might
produce surprising results. It's often best to drop any constraints
on the column before altering its type, and then add back suitably
modified constraints afterwards.
......@@ -1457,9 +1457,9 @@ REVOKE ALL ON accounts FROM PUBLIC;
in turn contain tables. Schemas also contain other kinds of named
objects, including data types, functions, and operators. The same
object name can be used in different schemas without conflict; for
example, both <literal>schema1</> and <literal>myschema</> may
example, both <literal>schema1</> and <literal>myschema</> can
contain tables named <literal>mytable</>. Unlike databases,
schemas are not rigidly separated: a user may access objects in any
schemas are not rigidly separated: a user can access objects in any
of the schemas in the database he is connected to, if he has
privileges to do so.
</para>
......@@ -1586,7 +1586,7 @@ CREATE SCHEMA <replaceable>schemaname</replaceable> AUTHORIZATION <replaceable>u
<para>
Schema names beginning with <literal>pg_</> are reserved for
system purposes and may not be created by users.
system purposes and cannot be created by users.
</para>
</sect2>
......@@ -1746,7 +1746,7 @@ SELECT 3 OPERATOR(pg_catalog.+) 4;
own. To allow that, the owner of the schema needs to grant the
<literal>USAGE</literal> privilege on the schema. To allow users
to make use of the objects in the schema, additional privileges
may need to be granted, as appropriate for the object.
might need to be granted, as appropriate for the object.
</para>
<para>
......@@ -1786,7 +1786,7 @@ REVOKE CREATE ON SCHEMA public FROM PUBLIC;
the search path. If it is not named explicitly in the path then
it is implicitly searched <emphasis>before</> searching the path's
schemas. This ensures that built-in names will always be
findable. However, you may explicitly place
findable. However, you can explicitly place
<literal>pg_catalog</> at the end of your search path if you
prefer to have user-defined names override built-in names.
</para>
......@@ -1794,7 +1794,7 @@ REVOKE CREATE ON SCHEMA public FROM PUBLIC;
<para>
In <productname>PostgreSQL</productname> versions before 7.3,
table names beginning with <literal>pg_</> were reserved. This is
no longer true: you may create such a table name if you wish, in
no longer true: you can create such a table name if you wish, in
any non-system schema. However, it's best to continue to avoid
such names, to ensure that you won't suffer a conflict if some
future version defines a system table named the same as your
......@@ -1993,7 +1993,7 @@ SELECT name, altitude
</para>
<para>
In some cases you may wish to know which table a particular row
In some cases you might wish to know which table a particular row
originated from. There is a system column called
<structfield>tableoid</structfield> in each table which can tell you the
originating table:
......@@ -2242,7 +2242,7 @@ VALUES ('New York', NULL, NULL, 'NY');
<listitem>
<para>
Bulk loads and deletes may be accomplished by adding or removing
Bulk loads and deletes can be accomplished by adding or removing
partitions, if that requirement is planned into the partitioning design.
<command>ALTER TABLE</> is far faster than a bulk operation.
It also entirely avoids the <command>VACUUM</command>
......@@ -2566,7 +2566,7 @@ DO INSTEAD
<para>
As we can see, a complex partitioning scheme could require a
substantial amount of DDL. In the above example we would be
creating a new partition each month, so it may be wise to write a
creating a new partition each month, so it might be wise to write a
script that generates the required DDL automatically.
</para>
......@@ -2624,7 +2624,7 @@ ALTER TABLE measurement_y2003m02 NO INHERIT measurement;
This allows further operations to be performed on the data before
it is dropped. For example, this is often a useful time to back up
the data using <command>COPY</>, <application>pg_dump</>, or
similar tools. It can also be a useful time to aggregate data
similar tools. It might also be a useful time to aggregate data
into smaller formats, perform other data manipulations, or run
reports.
</para>
......
doc/src/sgml/diskusage.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/diskusage.sgml,v 1.17 2006/09/16 00:30:12 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/diskusage.sgml,v 1.18 2007/01/31 20:56:16 momjian Exp $ -->
<chapter id="diskusage">
<title>Monitoring Disk Usage</title>
......@@ -21,7 +21,7 @@
there is also a <acronym>TOAST</> file associated with the table,
which is used to store values too wide to fit comfortably in the main
table (see <xref linkend="storage-toast">). There will be one index on the
<acronym>TOAST</> table, if present. There may also be indexes associated
<acronym>TOAST</> table, if present. There might also be indexes associated
with the base table. Each table and index is stored in a separate disk
file &mdash; possibly more than one file, if the file would exceed one
gigabyte. Naming conventions for these files are described in <xref
......@@ -117,9 +117,9 @@ SELECT relname, relpages FROM pg_class ORDER BY relpages DESC;
<para>
The most important disk monitoring task of a database administrator
is to make sure the disk doesn't grow full. A filled data disk will
not result in data corruption, but it may well prevent useful activity
not result in data corruption, but it might prevent useful activity
from occurring. If the disk holding the WAL files grows full, database
server panic and consequent shutdown may occur.
server panic and consequent shutdown might occur.
</para>
<para>
......
doc/src/sgml/dml.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/dml.sgml,v 1.14 2006/09/18 19:54:01 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/dml.sgml,v 1.15 2007/01/31 20:56:16 momjian Exp $ -->
<chapter id="dml">
<title>Data Manipulation</title>
......@@ -168,14 +168,14 @@ INSERT INTO products (product_no, name, price) VALUES
<programlisting>
UPDATE products SET price = 10 WHERE price = 5;
</programlisting>
This may cause zero, one, or many rows to be updated. It is not
This might cause zero, one, or many rows to be updated. It is not
an error to attempt an update that does not match any rows.
</para>
<para>
Let's look at that command in detail. First is the key word
<literal>UPDATE</literal> followed by the table name. As usual,
the table name may be schema-qualified, otherwise it is looked up
the table name can be schema-qualified, otherwise it is looked up
in the path. Next is the key word <literal>SET</literal> followed
by the column name, an equals sign and the new column value. The
new column value can be any scalar expression, not just a constant.
......
doc/src/sgml/docguide.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/docguide.sgml,v 1.68 2007/01/31 15:23:28 teodor Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/docguide.sgml,v 1.69 2007/01/31 20:56:17 momjian Exp $ -->
<appendix id="docguide">
<title>Documentation</title>
......@@ -79,7 +79,7 @@
<para>
The following tools are used to process the documentation. Some
may be optional, as noted.
might be optional, as noted.
<variablelist>
<varlistentry>
......@@ -168,7 +168,7 @@
<para>
We have documented experience with several installation methods for
the various tools that are needed to process the documentation.
These will be described below. There may be some other packaged
These will be described below. There might be some other packaged
distributions for these tools. Please report package status to the
documentation mailing list, and we will include that information
here.
......@@ -673,7 +673,7 @@ save_size.pdfjadetex = 10000
It appears that current versions of the <productname>PostgreSQL</productname> documentation
trigger some bug in or exceed the size limit of OpenJade. If the
build process of the <acronym>RTF</acronym> version hangs for a
long time and the output file still has size 0, then you may have
long time and the output file still has size 0, then you might have
hit that problem. (But keep in mind that a normal build takes 5
to 10 minutes, so don't abort too soon.)
</para>
......@@ -1010,7 +1010,7 @@ save_size.pdfjadetex = 10000
<para>
The <productname>PostgreSQL</productname> distribution includes a
parsed DTD definitions file <filename>reference.ced</filename>.
You may find that when using <productname>PSGML</productname>, a
You might find that when using <productname>PSGML</productname>, a
comfortable way of working with these separate files of book
parts is to insert a proper <literal>DOCTYPE</literal>
declaration while you're editing them. If you are working on
......@@ -1073,7 +1073,7 @@ save_size.pdfjadetex = 10000
<para>
Reference pages that describe executable commands should contain
the following sections, in this order. Sections that do not apply
may be omitted. Additional top-level sections should only be used
can be omitted. Additional top-level sections should only be used
in special circumstances; often that information belongs in the
<quote>Usage</quote> section.
......@@ -1114,7 +1114,7 @@ save_size.pdfjadetex = 10000
<listitem>
<para>
A list describing each command-line option. If there are a
lot of options, subsections may be used.
lot of options, subsections can be used.
</para>
</listitem>
</varlistentry>
......
doc/src/sgml/ecpg.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/ecpg.sgml,v 1.77 2006/10/23 18:10:31 petere Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/ecpg.sgml,v 1.78 2007/01/31 20:56:17 momjian Exp $ -->
<chapter id="ecpg">
<title><application>ECPG</application> - Embedded <acronym>SQL</acronym> in C</title>
......@@ -59,7 +59,7 @@
EXEC SQL ...;
</programlisting>
These statements syntactically take the place of a C statement.
Depending on the particular statement, they may appear at the
Depending on the particular statement, they can appear at the
global level or within a function. Embedded
<acronym>SQL</acronym> statements follow the case-sensitivity rules
of normal <acronym>SQL</acronym> code, and not those of C.
......@@ -127,7 +127,7 @@ EXEC SQL CONNECT TO <replaceable>target</replaceable> <optional>AS <replaceable>
(single-quoted) string literal or a variable reference. The
connection target <literal>DEFAULT</literal> initiates a connection
to the default database under the default user name. No separate
user name or connection name may be specified in that case.
user name or connection name can be specified in that case.
</para>
<para>
......@@ -160,7 +160,7 @@ EXEC SQL CONNECT TO <replaceable>target</replaceable> <optional>AS <replaceable>
</itemizedlist>
As above, the parameters <replaceable>username</replaceable> and
<replaceable>password</replaceable> may be an SQL identifier, an
<replaceable>password</replaceable> can be an SQL identifier, an
SQL string literal, or a reference to a character variable.
</para>
......@@ -694,7 +694,7 @@ EXEC SQL END DECLARE SECTION;
EXEC SQL EXECUTE IMMEDIATE :stmt;
</programlisting>
You may not execute statements that retrieve data (e.g.,
You cannot execute statements that retrieve data (e.g.,
<command>SELECT</command>) this way.
</para>
......@@ -728,7 +728,7 @@ EXEC SQL PREPARE mystmt FROM :stmt;
...
EXEC SQL EXECUTE mystmt INTO v1, v2, v3 USING 37;
</programlisting>
An <command>EXECUTE</command> command may have an
An <command>EXECUTE</command> command can have an
<literal>INTO</literal> clause, a <literal>USING</literal> clause,
both, or neither.
</para>
......@@ -3665,7 +3665,7 @@ risnull(CINTTYPE, (char *) &amp;i);
<command>FETCH</command> statement. An SQL descriptor area groups
the data of one row of data together with metadata items into one
data structure. The metadata is particularly useful when executing
dynamic SQL statements, where the nature of the result columns may
dynamic SQL statements, where the nature of the result columns might
not be known ahead of time.
</para>
......@@ -4310,7 +4310,7 @@ struct
<para>
The statement sent to the <productname>PostgreSQL</productname>
server was empty. (This cannot normally happen in an embedded
SQL program, so it may point to an internal error.) (SQLSTATE
SQL program, so it might point to an internal error.) (SQLSTATE
YE002)
</para>
</listitem>
......@@ -4689,7 +4689,7 @@ cc -o myprog prog1.o prog2.o ... -lecpg
<para>
If you manage the build process of a larger project using
<application>make</application>, it may be convenient to include
<application>make</application>, it might be convenient to include
the following implicit rule to your makefiles:
<programlisting>
ECPG = ecpg
......@@ -4949,7 +4949,7 @@ EXEC SQL OPEN <replaceable>cursor</replaceable>;
<para>
Here is a complete example describing the output of the
preprocessor of a file <filename>foo.pgc</filename> (details may
preprocessor of a file <filename>foo.pgc</filename> (details might
change with each particular version of the preprocessor):
<programlisting>
EXEC SQL BEGIN DECLARE SECTION;
......
doc/src/sgml/errcodes.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/errcodes.sgml,v 1.21 2006/12/24 00:29:17 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/errcodes.sgml,v 1.22 2007/01/31 20:56:17 momjian Exp $ -->
<appendix id="errcodes-appendix">
<title><productname>PostgreSQL</productname> Error Codes</title>
......@@ -27,7 +27,7 @@
According to the standard, the first two characters of an error code
denote a class of errors, while the last three characters indicate
a specific condition within that class. Thus, an application that
does not recognize the specific error code may still be able to infer
does not recognize the specific error code can still be able to infer
what to do from the error class.
</para>
......
doc/src/sgml/extend.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/extend.sgml,v 1.32 2006/09/16 00:30:13 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/extend.sgml,v 1.33 2007/01/31 20:56:17 momjian Exp $ -->
<chapter id="extend">
<title>Extending <acronym>SQL</acronym></title>
......@@ -145,7 +145,7 @@
<para>
A domain is based on a particular base type and for many purposes
is interchangeable with its base type. However, a domain may
is interchangeable with its base type. However, a domain can
have constraints that restrict its valid values to a subset of
what the underlying base type would allow.
</para>
......
doc/src/sgml/external-projects.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/external-projects.sgml,v 1.14 2006/11/20 17:42:16 neilc Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/external-projects.sgml,v 1.15 2007/01/31 20:56:17 momjian Exp $ -->
<appendix id="external-projects">
<title>External Projects</title>
......@@ -68,7 +68,7 @@
All other language interfaces are external projects and are distributed
separately. <xref linkend="language-interface-table"> includes a list of
some of these projects. Note that some of these packages may not be
some of these projects. Note that some of these packages might not be
released under the same license as <productname>PostgreSQL</>. For more
information on each language interface, including licensing terms, refer to
its website and documentation.
......@@ -175,7 +175,7 @@
In addition, there are a number of procedural languages that are developed
and maintained outside the core <productname>PostgreSQL</productname>
distribution. <xref linkend="pl-language-table"> lists some of these
packages. Note that some of these projects may not be released under the same
packages. Note that some of these projects might not be released under the same
license as <productname>PostgreSQL</>. For more information on each
procedural language, including licensing information, refer to its website
and documentation.
......
doc/src/sgml/features.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/features.sgml,v 2.25 2006/09/16 00:30:13 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/features.sgml,v 2.26 2007/01/31 20:56:17 momjian Exp $ -->
<appendix id="features">
<title>SQL Conformance</title>
......@@ -26,7 +26,7 @@
9075 Working Group during the preparation of SQL:2003. Even so,
many of the features required by SQL:2003 are already supported,
though sometimes with slightly differing syntax or function.
Further moves towards conformance may be expected in later releases.
Further moves towards conformance should be expected in later releases.
</para>
<para>
......@@ -80,7 +80,7 @@
PostgreSQL supports most of the major features of SQL:2003. Out of
164 mandatory features required for full Core conformance,
PostgreSQL conforms to at least 150. In addition, there is a long
list of supported optional features. It may be worth noting that at
list of supported optional features. It might be worth noting that at
the time of writing, no current version of any database management
system claims full conformance to Core SQL:2003.
</para>
......@@ -90,9 +90,9 @@
that <productname>PostgreSQL</productname> supports, followed by a
list of the features defined in <acronym>SQL:2003</acronym> which
are not yet supported in <productname>PostgreSQL</productname>.
Both of these lists are approximate: There may be minor details that
Both of these lists are approximate: There might be minor details that
are nonconforming for a feature that is listed as supported, and
large parts of an unsupported feature may in fact be implemented.
large parts of an unsupported feature might in fact be implemented.
The main body of the documentation always contains the most accurate
information about what does and does not work.
</para>
......
doc/src/sgml/func.sgml
View file @ a134ee33
This diff is collapsed.
doc/src/sgml/gin.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/gin.sgml,v 2.8 2007/01/31 15:09:45 teodor Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/gin.sgml,v 2.9 2007/01/31 20:56:17 momjian Exp $ -->
<chapter id="GIN">
<title>GIN Indexes</title>
......@@ -15,7 +15,7 @@
<acronym>GIN</acronym> stands for Generalized Inverted Index. It is
an index structure storing a set of (key, posting list) pairs, where
a <quote>posting list</> is a set of rows in which the key occurs. Each
indexed value may contain many keys, so the same row ID may appear in
indexed value can contain many keys, so the same row ID can appear in
multiple posting lists.
</para>
......@@ -115,7 +115,7 @@
<listitem>
<para>
Returns TRUE if the indexed value satisfies the query operator with
strategy number <literal>n</> (or may satisfy, if the operator is
strategy number <literal>n</> (or would satisfy, if the operator is
marked RECHECK in the operator class). The <literal>check</> array has
the same length as the number of keys previously returned by
<function>extractQuery</> for this query. Each element of the
......@@ -222,7 +222,7 @@
</para>
<para>
<acronym>GIN</acronym> searches keys only by equality matching. This may
<acronym>GIN</acronym> searches keys only by equality matching. This might
be improved in future.
</para>
</sect1>
......
doc/src/sgml/gist.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/gist.sgml,v 1.27 2006/10/23 18:10:31 petere Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/gist.sgml,v 1.28 2007/01/31 20:56:17 momjian Exp $ -->
<chapter id="GiST">
<title>GiST Indexes</title>
......@@ -248,7 +248,7 @@
Usually, replay of the WAL log is sufficient to restore the integrity
of a GiST index following a database crash. However, there are some
corner cases in which the index state is not fully rebuilt. The index
will still be functionally correct, but there may be some performance
will still be functionally correct, but there might be some performance
degradation. When this occurs, the index can be repaired by
<command>VACUUM</>ing its table, or by rebuilding the index using
<command>REINDEX</>. In some cases a plain <command>VACUUM</> is
......
doc/src/sgml/indexam.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.20 2007/01/20 23:13:01 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.21 2007/01/31 20:56:17 momjian Exp $ -->
<chapter id="indexam">
<title>Index Access Method Interface Definition</title>
......@@ -33,7 +33,7 @@
block number and an item number within that block (see <xref
linkend="storage-page-layout">). This is sufficient
information to fetch a particular row version from the table.
Indexes are not directly aware that under MVCC, there may be multiple
Indexes are not directly aware that under MVCC, there might be multiple
extant versions of the same logical row; to an index, each tuple is
an independent object that needs its own index entry. Thus, an
update of a row always creates all-new index entries for the row, even if
......@@ -174,7 +174,7 @@ aminsert (Relation indexRelation,
<literal>heap_tid</> is the TID to be indexed.
If the access method supports unique indexes (its
<structname>pg_am</>.<structfield>amcanunique</> flag is true) then
<literal>check_uniqueness</> may be true, in which case the access method
<literal>check_uniqueness</> might be true, in which case the access method
must verify that there is no conflicting row; this is the only situation in
which the access method normally needs the <literal>heapRelation</>
parameter. See <xref linkend="index-unique-checks"> for details.
......@@ -205,7 +205,7 @@ ambulkdelete (IndexVacuumInfo *info,
<para>
Because of limited <varname>maintenance_work_mem</>,
<function>ambulkdelete</> may need to be called more than once when many
<function>ambulkdelete</> might need to be called more than once when many
tuples are to be deleted. The <literal>stats</> argument is the result
of the previous call for this index (it is NULL for the first call within a
<command>VACUUM</> operation). This allows the AM to accumulate statistics
......@@ -222,7 +222,7 @@ amvacuumcleanup (IndexVacuumInfo *info,
</programlisting>
Clean up after a <command>VACUUM</command> operation (zero or more
<function>ambulkdelete</> calls). This does not have to do anything
beyond returning index statistics, but it may perform bulk cleanup
beyond returning index statistics, but it might perform bulk cleanup
such as reclaiming empty index pages. <literal>stats</> is whatever the
last <function>ambulkdelete</> call returned, or NULL if
<function>ambulkdelete</> was not called because no tuples needed to be
......@@ -418,7 +418,7 @@ amrestrpos (IndexScanDesc scan);
</para>
<para>
The operator family may indicate that the index is <firstterm>lossy</> for a
The operator family can indicate that the index is <firstterm>lossy</> for a
particular operator; this implies that the index scan will return all the
entries that pass the scan key, plus possibly additional entries that do
not. The core system's index-scan machinery will then apply that operator
......@@ -467,7 +467,7 @@ amrestrpos (IndexScanDesc scan);
<para>
The access method must support <quote>marking</> a position in a scan
and later returning to the marked position. The same position may be
and later returning to the marked position. The same position might be
restored multiple times. However, only one position need be remembered
per scan; a new <function>ammarkpos</> call overrides the previously
marked position.
......@@ -480,7 +480,7 @@ amrestrpos (IndexScanDesc scan);
would have found the entry if it had existed when the scan started, or for
the scan to return such an entry upon rescanning or backing
up even though it had not been returned the first time through. Similarly,
a concurrent delete may or may not be reflected in the results of a scan.
a concurrent delete might or might not be reflected in the results of a scan.
What is important is that insertions or deletions not cause the scan to
miss or multiply return entries that were not themselves being inserted or
deleted.
......@@ -518,7 +518,7 @@ amrestrpos (IndexScanDesc scan);
<literal>RowExclusiveLock</> when updating the index (including plain
<command>VACUUM</>). Since these lock
types do not conflict, the access method is responsible for handling any
fine-grained locking it may need. An exclusive lock on the index as a whole
fine-grained locking it might need. An exclusive lock on the index as a whole
will be taken only during index creation, destruction,
<command>REINDEX</>, or <command>VACUUM FULL</>.
</para>
......@@ -537,7 +537,7 @@ amrestrpos (IndexScanDesc scan);
<firstterm>heap</>) and the index. Because
<productname>PostgreSQL</productname> separates accesses
and updates of the heap from those of the index, there are windows in
which the index may be inconsistent with the heap. We handle this problem
which the index might be inconsistent with the heap. We handle this problem
with the following rules:
<itemizedlist>
......@@ -582,7 +582,7 @@ amrestrpos (IndexScanDesc scan);
against this scenario by requiring the scan keys to be rechecked
against the heap row in all cases, but that is too expensive. Instead,
we use a pin on an index page as a proxy to indicate that the reader
may still be <quote>in flight</> from the index entry to the matching
might still be <quote>in flight</> from the index entry to the matching
heap entry. Making <function>ambulkdelete</> block on such a pin ensures
that <command>VACUUM</> cannot delete the heap entry before the reader
is done with it. This solution costs little in run time, and adds blocking
......@@ -595,7 +595,7 @@ amrestrpos (IndexScanDesc scan);
entry. This is expensive for a number of reasons. An
<quote>asynchronous</> scan in which we collect many TIDs from the index,
and only visit the heap tuples sometime later, requires much less index
locking overhead and may allow a more efficient heap access pattern.
locking overhead and can allow a more efficient heap access pattern.
Per the above analysis, we must use the synchronous approach for
non-MVCC-compliant snapshots, but an asynchronous scan is workable
for a query using an MVCC snapshot.
......
doc/src/sgml/indices.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/indices.sgml,v 1.67 2006/12/23 00:43:08 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/indices.sgml,v 1.68 2007/01/31 20:56:17 momjian Exp $ -->
<chapter id="indexes">
<title id="indexes-title">Indexes</title>
......@@ -74,12 +74,12 @@ CREATE INDEX test1_id_index ON test1 (id);
Once an index is created, no further intervention is required: the
system will update the index when the table is modified, and it will
use the index in queries when it thinks this would be more efficient
than a sequential table scan. But you may have to run the
than a sequential table scan. But you might have to run the
<command>ANALYZE</command> command regularly to update
statistics to allow the query planner to make educated decisions.
See <xref linkend="performance-tips"> for information about
how to find out whether an index is used and when and why the
planner may choose <emphasis>not</emphasis> to use an index.
planner might choose <emphasis>not</emphasis> to use an index.
</para>
<para>
......@@ -193,7 +193,7 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
indexes to perform no better than B-tree indexes, and the
index size and build time for hash indexes is much worse.
Furthermore, hash index operations are not presently WAL-logged,
so hash indexes may need to be rebuilt with <command>REINDEX</>
so hash indexes might need to be rebuilt with <command>REINDEX</>
after a database crash.
For these reasons, hash index use is presently discouraged.
</para>
......@@ -296,7 +296,7 @@ CREATE TABLE test2 (
<programlisting>
SELECT name FROM test2 WHERE major = <replaceable>constant</replaceable> AND minor = <replaceable>constant</replaceable>;
</programlisting>
then it may be appropriate to define an index on the columns
then it might be appropriate to define an index on the columns
<structfield>major</structfield> and
<structfield>minor</structfield> together, e.g.,
<programlisting>
......@@ -306,7 +306,7 @@ CREATE INDEX test2_mm_idx ON test2 (major, minor);
<para>
Currently, only the B-tree and GiST index types support multicolumn
indexes. Up to 32 columns may be specified. (This limit can be
indexes. Up to 32 columns can be specified. (This limit can be
altered when building <productname>PostgreSQL</productname>; see the
file <filename>pg_config_manual.h</filename>.)
</para>
......@@ -413,7 +413,7 @@ CREATE INDEX test2_mm_idx ON test2 (major, minor);
<para>
In all but the simplest applications, there are various combinations of
indexes that may be useful, and the database developer must make
indexes that might be useful, and the database developer must make
trade-offs to decide which indexes to provide. Sometimes multicolumn
indexes are best, but sometimes it's better to create separate indexes
and rely on the index-combination feature. For example, if your
......@@ -450,7 +450,7 @@ CREATE INDEX test2_mm_idx ON test2 (major, minor);
</indexterm>
<para>
Indexes may also be used to enforce uniqueness of a column's value,
Indexes can also be used to enforce uniqueness of a column's value,
or the uniqueness of the combined values of more than one column.
<synopsis>
CREATE UNIQUE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable> (<replaceable>column</replaceable> <optional>, ...</optional>);
......@@ -538,7 +538,7 @@ CREATE INDEX people_names ON people ((first_name || ' ' || last_name));
<para>
The syntax of the <command>CREATE INDEX</> command normally requires
writing parentheses around index expressions, as shown in the second
example. The parentheses may be omitted when the expression is just
example. The parentheses can be omitted when the expression is just
a function call, as in the first example.
</para>
......@@ -687,7 +687,7 @@ SELECT * FROM orders WHERE billed is not true AND amount &gt; 5000.00;
<programlisting>
SELECT * FROM orders WHERE order_nr = 3501;
</programlisting>
The order 3501 may be among the billed or among the unbilled
The order 3501 might be among the billed or among the unbilled
orders.
</para>
</example>
......@@ -755,8 +755,8 @@ CREATE UNIQUE INDEX tests_success_constraint ON tests (subject, target)
<para>
Finally, a partial index can also be used to override the system's
query plan choices. It may occur that data sets with peculiar
distributions will cause the system to use an index when it really
query plan choices. Also, data sets with peculiar
distributions might cause the system to use an index when it really
should not. In that case the index can be set up so that it is not
available for the offending query. Normally,
<productname>PostgreSQL</> makes reasonable choices about index
......@@ -795,7 +795,7 @@ CREATE UNIQUE INDEX tests_success_constraint ON tests (subject, target)
</indexterm>
<para>
An index definition may specify an <firstterm>operator
An index definition can specify an <firstterm>operator
class</firstterm> for each column of an index.
<synopsis>
CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable> (<replaceable>column</replaceable> <replaceable>opclass</replaceable> <optional>, ...</optional>);
......@@ -994,15 +994,15 @@ SELECT am.amname AS index_method,
via run-time parameters (described in <xref
linkend="runtime-config-query-constants">).
An inaccurate selectivity estimate is due to
insufficient statistics. It may be possible to improve this by
insufficient statistics. It might be possible to improve this by
tuning the statistics-gathering parameters (see
<xref linkend="sql-altertable" endterm="sql-altertable-title">).
</para>
<para>
If you do not succeed in adjusting the costs to be more
appropriate, then you may have to resort to forcing index usage
explicitly. You may also want to contact the
appropriate, then you might have to resort to forcing index usage
explicitly. You might also want to contact the
<productname>PostgreSQL</> developers to examine the issue.
</para>
</listitem>
......
doc/src/sgml/information_schema.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/information_schema.sgml,v 1.29 2006/10/23 18:10:31 petere Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/information_schema.sgml,v 1.30 2007/01/31 20:56:17 momjian Exp $ -->
<chapter id="information-schema">
<title>The Information Schema</title>
......@@ -170,7 +170,7 @@
<entry><literal>grantee</literal></entry>
<entry><type>sql_identifier</type></entry>
<entry>
Name of the role to which this role membership was granted (may
Name of the role to which this role membership was granted (can
be the current user, or a different role in case of nested role
memberships)
</entry>
......@@ -222,7 +222,7 @@
<entry><literal>grantee</literal></entry>
<entry><type>sql_identifier</type></entry>
<entry>
Name of the role to which this role membership was granted (may
Name of the role to which this role membership was granted (can
be the current user, or a different role in case of nested role
memberships)
</entry>
......@@ -357,7 +357,7 @@
If <literal>data_type</literal> identifies a numeric type, this
column contains the (declared or implicit) precision of the
type for this attribute. The precision indicates the number of
significant digits. It may be expressed in decimal (base 10)
significant digits. It can be expressed in decimal (base 10)
or binary (base 2) terms, as specified in the column
<literal>numeric_precision_radix</literal>. For all other data
types, this column is null.
......@@ -383,7 +383,7 @@
If <literal>data_type</literal> identifies an exact numeric
type, this column contains the (declared or implicit) scale of
the type for this attribute. The scale indicates the number of
significant digits to the right of the decimal point. It may
significant digits to the right of the decimal point. It can
be expressed in decimal (base 10) or binary (base 2) terms, as
specified in the column
<literal>numeric_precision_radix</literal>. For all other data
......@@ -916,7 +916,7 @@
<literal>YES</literal> if the column is possibly nullable,
<literal>NO</literal> if it is known not nullable. A not-null
constraint is one way a column can be known not nullable, but
there may be others.
there can be others.
</entry>
</row>
......@@ -964,7 +964,7 @@
If <literal>data_type</literal> identifies a numeric type, this
column contains the (declared or implicit) precision of the
type for this column. The precision indicates the number of
significant digits. It may be expressed in decimal (base 10)
significant digits. It can be expressed in decimal (base 10)
or binary (base 2) terms, as specified in the column
<literal>numeric_precision_radix</literal>. For all other data
types, this column is null.
......@@ -990,7 +990,7 @@
If <literal>data_type</literal> identifies an exact numeric
type, this column contains the (declared or implicit) scale of
the type for this column. The scale indicates the number of
significant digits to the right of the decimal point. It may
significant digits to the right of the decimal point. It can
be expressed in decimal (base 10) or binary (base 2) terms, as
specified in the column
<literal>numeric_precision_radix</literal>. For all other data
......@@ -1227,7 +1227,7 @@
is supposed to identify the underlying built-in type of the column.
In <productname>PostgreSQL</productname>, this means that the type
is defined in the system catalog schema
<literal>pg_catalog</literal>. This column may be useful if the
<literal>pg_catalog</literal>. This column might be useful if the
application can handle the well-known built-in types specially (for
example, format the numeric types differently or use the data in
the precision columns). The columns <literal>udt_name</literal>,
......@@ -1738,7 +1738,7 @@
If the domain has a numeric type, this column contains the
(declared or implicit) precision of the type for this column.
The precision indicates the number of significant digits. It
may be expressed in decimal (base 10) or binary (base 2) terms,
can be expressed in decimal (base 10) or binary (base 2) terms,
as specified in the column
<literal>numeric_precision_radix</literal>. For all other data
types, this column is null.
......@@ -1764,7 +1764,7 @@
If the domain has an exact numeric type, this column contains
the (declared or implicit) scale of the type for this column.
The scale indicates the number of significant digits to the
right of the decimal point. It may be expressed in decimal
right of the decimal point. It can be expressed in decimal
(base 10) or binary (base 2) terms, as specified in the column
<literal>numeric_precision_radix</literal>. For all other data
types, this column is null.
......@@ -2126,7 +2126,7 @@ ORDER BY c.ordinal_position;
<para>
For permission checking, the set of <quote>applicable roles</quote>
is applied, which may be broader than the set of enabled roles. So
is applied, which can be broader than the set of enabled roles. So
generally, it is better to use the view
<literal>applicable_roles</literal> instead of this one; see also
there.
......@@ -2753,7 +2753,7 @@ ORDER BY c.ordinal_position;
<row>
<entry><literal>routine_name</literal></entry>
<entry><type>sql_identifier</type></entry>
<entry>Name of the function (may be duplicated in case of overloading)</entry>
<entry>Name of the function (might be duplicated in case of overloading)</entry>
</row>
<row>
......@@ -2863,7 +2863,7 @@ ORDER BY c.ordinal_position;
applies to domains, and since domains do not have real privileges
in <productname>PostgreSQL</productname>, this view is empty.
Further information can be found under
<literal>usage_privileges</literal>. In the future, this view may
<literal>usage_privileges</literal>. In the future, this view might
contain more useful information.
</para>
......@@ -3003,7 +3003,7 @@ ORDER BY c.ordinal_position;
<row>
<entry><literal>routine_name</literal></entry>
<entry><type>sql_identifier</type></entry>
<entry>Name of the function (may be duplicated in case of overloading)</entry>
<entry>Name of the function (might be duplicated in case of overloading)</entry>
</row>
<row>
......@@ -3084,7 +3084,7 @@ ORDER BY c.ordinal_position;
<row>
<entry><literal>routine_name</literal></entry>
<entry><type>sql_identifier</type></entry>
<entry>Name of the function (may be duplicated in case of overloading)</entry>
<entry>Name of the function (might be duplicated in case of overloading)</entry>
</row>
<row>
......@@ -3737,7 +3737,7 @@ ORDER BY c.ordinal_position;
<entry>
This column contains the (declared or implicit) precision of
the sequence data type (see above). The precision indicates
the number of significant digits. It may be expressed in
the number of significant digits. It can be expressed in
decimal (base 10) or binary (base 2) terms, as specified in the
column <literal>numeric_precision_radix</literal>.
</entry>
......@@ -3761,7 +3761,7 @@ ORDER BY c.ordinal_position;
This column contains the (declared or implicit) scale of the
sequence data type (see above). The scale indicates the number
of significant digits to the right of the decimal point. It
may be expressed in decimal (base 10) or binary (base 2) terms,
can be expressed in decimal (base 10) or binary (base 2) terms,
as specified in the column
<literal>numeric_precision_radix</literal>.
</entry>
......@@ -4700,7 +4700,7 @@ ORDER BY c.ordinal_position;
incompatibilities with the SQL standard that affect the
representation in the information schema. First, trigger names are
local to the table in <productname>PostgreSQL</productname>, rather
than being independent schema objects. Therefore there may be duplicate
than being independent schema objects. Therefore there can be duplicate
trigger names defined in one schema, as long as they belong to
different tables. (<literal>trigger_catalog</literal> and
<literal>trigger_schema</literal> are really the values pertaining
......@@ -4734,7 +4734,7 @@ ORDER BY c.ordinal_position;
in <productname>PostgreSQL</productname>, this view shows implicit
<literal>USAGE</literal> privileges granted to
<literal>PUBLIC</literal> for all domains. In the future, this
view may contain more useful information.
view might contain more useful information.
</para>
<table>
......
doc/src/sgml/installation.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.278 2007/01/29 21:49:17 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.279 2007/01/31 20:56:17 momjian Exp $ -->
<chapter id="installation">
<title><![%standalone-include[<productname>PostgreSQL</>]]>
......@@ -1027,7 +1027,7 @@ su - postgres
executables considerably, and on non-GCC compilers it usually
also disables compiler optimization, causing slowdowns. However,
having the symbols available is extremely helpful for dealing
with any problems that may arise. Currently, this option is
with any problems that might arise. Currently, this option is
recommended for production installations only if you use GCC.
But you should always have it on if you are doing development work
or running a beta version.
......@@ -1414,7 +1414,7 @@ All of PostgreSQL is successfully made. Ready to install.
investigates (for example, software upgrades), then it's a good
idea to do <command>gmake distclean</> before reconfiguring and
rebuilding. Without this, your changes in configuration choices
may not propagate everywhere they need to.
might not propagate everywhere they need to.
</para>
</sect1>
......@@ -1636,7 +1636,7 @@ nohup /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data \
</para>
<para>
To stop a server running in the background you can type
To stop a server running in the background you can type:
<programlisting>
kill `cat /usr/local/pgsql/data/postmaster.pid`
</programlisting>
......
doc/src/sgml/intro.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/intro.sgml,v 1.31 2006/03/10 19:10:48 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/intro.sgml,v 1.32 2007/01/31 20:56:17 momjian Exp $ -->
<preface id="preface">
<title>Preface</title>
......@@ -74,7 +74,7 @@
<listitem>
<para>
<xref linkend="internals"> contains assorted information that may be of
<xref linkend="internals"> contains assorted information that might be of
use to <productname>PostgreSQL</> developers.
</para>
</listitem>
......
doc/src/sgml/libpq.sgml
View file @ a134ee33
This diff is collapsed.
doc/src/sgml/lobj.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/lobj.sgml,v 1.42 2006/10/23 18:10:31 petere Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/lobj.sgml,v 1.43 2007/01/31 20:56:17 momjian Exp $ -->
<chapter id="largeObjects">
<title id="largeObjects-title">Large Objects</title>
......@@ -20,7 +20,7 @@
large object data. We use the <application>libpq</application> C
library for the examples in this chapter, but most programming
interfaces native to <productname>PostgreSQL</productname> support
equivalent functionality. Other interfaces may use the large
equivalent functionality. Other interfaces might use the large
object interface internally to provide generic support for large
values. This is not described here.
</para>
......@@ -305,7 +305,7 @@ int lo_tell(PGconn *conn, int fd);
<title>Closing a Large Object Descriptor</title>
<para>
A large object descriptor may be closed by calling
A large object descriptor can be closed by calling
<synopsis>
int lo_close(PGconn *conn, int fd);
</synopsis>
......@@ -392,7 +392,7 @@ SELECT lo_export(image.raster, '/tmp/motd') FROM image
<para>
<xref linkend="lo-example"> is a sample program which shows how the large object
interface
in <application>libpq</> can be used. Parts of the program are
in <application>libpq</> can be used. Parts of the program are
commented out but are left in the source for the reader's
benefit. This program can also be found in
<filename>src/test/examples/testlo.c</filename> in the source distribution.
......
doc/src/sgml/maintenance.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.67 2007/01/31 04:13:22 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.68 2007/01/31 20:56:17 momjian Exp $ -->
<chapter id="maintenance">
<title>Routine Database Maintenance Tasks</title>
......@@ -131,7 +131,7 @@
<para>
Clearly, a table that receives frequent updates or deletes will need
to be vacuumed more often than tables that are seldom updated. It
may be useful to set up periodic <application>cron</> tasks that
might be useful to set up periodic <application>cron</> tasks that
<command>VACUUM</command> only selected tables, skipping tables that are known not to
change often. This is only likely to be helpful if you have both
large heavily-updated tables and large seldom-updated tables &mdash; the
......@@ -185,7 +185,7 @@
If you have multiple databases
in a cluster, don't forget to <command>VACUUM</command> each one;
the program <xref linkend="app-vacuumdb" endterm="app-vacuumdb-title">
may be helpful.
might be helpful.
</para>
<para>
......@@ -226,14 +226,14 @@
generate good plans for queries. These statistics are gathered by
the <command>ANALYZE</> command, which can be invoked by itself or
as an optional step in <command>VACUUM</>. It is important to have
reasonably accurate statistics, otherwise poor choices of plans may
reasonably accurate statistics, otherwise poor choices of plans might
degrade database performance.
</para>
<para>
As with vacuuming for space recovery, frequent updates of statistics
are more useful for heavily-updated tables than for seldom-updated
ones. But even for a heavily-updated table, there may be no need for
ones. But even for a heavily-updated table, there might be no need for
statistics updates if the statistical distribution of the data is
not changing much. A simple rule of thumb is to think about how much
the minimum and maximum values of the columns in the table change.
......@@ -241,7 +241,7 @@
of row update will have a constantly-increasing maximum value as
rows are added and updated; such a column will probably need more
frequent statistics updates than, say, a column containing URLs for
pages accessed on a website. The URL column may receive changes just
pages accessed on a website. The URL column might receive changes just
as often, but the statistical distribution of its values probably
changes relatively slowly.
</para>
......@@ -257,11 +257,11 @@
<tip>
<para>
Although per-column tweaking of <command>ANALYZE</> frequency may not be
very productive, you may well find it worthwhile to do per-column
Although per-column tweaking of <command>ANALYZE</> frequency might not be
very productive, you might well find it worthwhile to do per-column
adjustment of the level of detail of the statistics collected by
<command>ANALYZE</>. Columns that are heavily used in <literal>WHERE</> clauses
and have highly irregular data distributions may require a finer-grain
and have highly irregular data distributions might require a finer-grain
data histogram than other columns. See <command>ALTER TABLE SET
STATISTICS</>.
</para>
......@@ -271,7 +271,7 @@
Recommended practice for most sites is to schedule a database-wide
<command>ANALYZE</> once a day at a low-usage time of day; this can
usefully be combined with a nightly <command>VACUUM</>. However,
sites with relatively slowly changing table statistics may find that
sites with relatively slowly changing table statistics might find that
this is overkill, and that less-frequent <command>ANALYZE</> runs
are sufficient.
</para>
......@@ -381,7 +381,7 @@
<para>
One disadvantage of decreasing <varname>vacuum_freeze_min_age</> is that
it may cause <command>VACUUM</> to do useless work: changing a table row's
it might cause <command>VACUUM</> to do useless work: changing a table row's
XID to <literal>FrozenXID</> is a waste of time if the row is modified
soon thereafter (causing it to acquire a new XID). So the setting should
be large enough that rows are not frozen until they are unlikely to change
......@@ -510,7 +510,7 @@ vacuum threshold = vacuum base threshold + vacuum scale factor * number of tuple
The number of obsolete tuples is obtained from the statistics
collector; it is a semi-accurate count updated by each
<command>UPDATE</command> and <command>DELETE</command> operation. (It
is only semi-accurate because some information may be lost under heavy
is only semi-accurate because some information might be lost under heavy
load.) For analyze, a similar condition is used: the threshold, defined as
<programlisting>
analyze threshold = analyze base threshold + analyze scale factor * number of tuples
......@@ -658,7 +658,7 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
<command>postgres</command> into a
file, you will have log output, but
the only way to truncate the log file is to stop and restart
the server. This may be OK if you are using
the server. This might be OK if you are using
<productname>PostgreSQL</productname> in a development environment,
but few production servers would find this behavior acceptable.
</para>
......@@ -707,7 +707,7 @@ pg_ctl start | rotatelogs /var/log/pgsql_log 86400
<para>
On many systems, however, <application>syslog</> is not very reliable,
particularly with large log messages; it may truncate or drop messages
particularly with large log messages; it might truncate or drop messages
just when you need them the most. Also, on <productname>Linux</>,
<application>syslog</> will sync each message to disk, yielding poor
performance. (You can use a <literal>-</> at the start of the file name
......
doc/src/sgml/manage-ag.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.51 2007/01/22 02:47:56 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.52 2007/01/31 20:56:17 momjian Exp $ -->
<chapter id="managing-databases">
<title>Managing Databases</title>
......@@ -143,7 +143,7 @@ createdb <replaceable class="parameter">dbname</replaceable>
exactly as described above.
The <xref linkend="app-createdb"> reference page contains the invocation
details. Note that <command>createdb</> without any arguments will create
a database with the current user name, which may or may not be what
a database with the current user name, which might or might not be what
you want.
</para>
......@@ -204,7 +204,7 @@ createdb -O <replaceable>rolename</> <replaceable>dbname</>
<literal>pg_dump</> dump: the dump script should be restored in a
virgin database to ensure that one recreates the correct contents
of the dumped database, without any conflicts with additions that
may now be present in <literal>template1</>.
can now be present in <literal>template1</>.
</para>
<para>
......@@ -221,7 +221,7 @@ createdb -T template0 <replaceable>dbname</>
<para>
It is possible to create additional template databases, and indeed
one may copy any database in a cluster by specifying its name
one can copy any database in a cluster by specifying its name
as the template for <command>CREATE DATABASE</>. It is important to
understand, however, that this is not (yet) intended as
a general-purpose <quote><command>COPY DATABASE</command></quote> facility.
......@@ -236,11 +236,11 @@ createdb -T template0 <replaceable>dbname</>
Two useful flags exist in <literal>pg_database</literal><indexterm><primary>pg_database</></> for each
database: the columns <literal>datistemplate</literal> and
<literal>datallowconn</literal>. <literal>datistemplate</literal>
may be set to indicate that a database is intended as a template for
<command>CREATE DATABASE</>. If this flag is set, the database may be
can be set to indicate that a database is intended as a template for
<command>CREATE DATABASE</>. If this flag is set, the database can be
cloned by
any user with <literal>CREATEDB</> privileges; if it is not set, only superusers
and the owner of the database may clone it.
and the owner of the database can clone it.
If <literal>datallowconn</literal> is false, then no new connections
to that database will be allowed (but existing sessions are not killed
simply by setting the flag false). The <literal>template0</literal>
......@@ -265,7 +265,7 @@ createdb -T template0 <replaceable>dbname</>
The <literal>postgres</> database is also created when a database
cluster is initialized. This database is meant as a default database for
users and applications to connect to. It is simply a copy of
<literal>template1</> and may be dropped and recreated if required.
<literal>template1</> and can be dropped and recreated if required.
</para>
</note>
</sect1>
......
doc/src/sgml/monitoring.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/monitoring.sgml,v 1.43 2006/12/08 19:16:17 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/monitoring.sgml,v 1.44 2007/01/31 20:56:18 momjian Exp $ -->
<chapter id="monitoring">
<title>Monitoring Database Activity</title>
......@@ -26,7 +26,7 @@
but one should not neglect regular Unix monitoring programs such as
<command>ps</>, <command>top</>, <command>iostat</>, and <command>vmstat</>.
Also, once one has identified a
poorly-performing query, further investigation may be needed using
poorly-performing query, further investigation might be needed using
<productname>PostgreSQL</productname>'s <xref linkend="sql-explain"
endterm="sql-explain-title"> command.
<xref linkend="using-explain"> discusses <command>EXPLAIN</>
......@@ -75,7 +75,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
The user, database, and connection source host items remain the same for
the life of the client connection, but the activity indicator changes.
The activity may be <literal>idle</> (i.e., waiting for a client command),
The activity can be <literal>idle</> (i.e., waiting for a client command),
<literal>idle in transaction</> (waiting for client inside a <command>BEGIN</> block),
or a command type name such as <literal>SELECT</>. Also,
<literal>waiting</> is attached if the server process is presently waiting
......@@ -141,7 +141,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
<para>
The parameter <xref linkend="guc-stats-start-collector"> must be
set to <literal>true</> for the statistics collector to be launched
at all. This is the default and recommended setting, but it may be
at all. This is the default and recommended setting, but it can be
turned off if you have no interest in statistics and want to
squeeze out every last drop of overhead. (The savings is likely to
be small, however.) Note that this option cannot be changed while
......@@ -423,8 +423,8 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
invoking a kernel call. However, these statistics do not give the
entire story: due to the way in which <productname>PostgreSQL</>
handles disk I/O, data that is not in the
<productname>PostgreSQL</> buffer cache may still reside in the
kernel's I/O cache, and may therefore still be fetched without
<productname>PostgreSQL</> buffer cache might still reside in the
kernel's I/O cache, and might therefore still be fetched without
requiring a physical read. Users interested in obtaining more
detailed information on <productname>PostgreSQL</> I/O behavior are
advised to use the <productname>PostgreSQL</> statistics collector
......@@ -971,7 +971,7 @@ Total time (ns) 2312105013
</para>
<para>
You should remember that trace programs need to be carefully written and
debugged prior to their use, otherwise the trace information collected may
debugged prior to their use, otherwise the trace information collected might
be meaningless. In most cases where problems are found it is the
instrumentation that is at fault, not the underlying system. When
discussing information found using dynamic tracing, be sure to enclose
......@@ -1027,7 +1027,7 @@ StartTransaction(void)
</para>
<para>
The dynamic tracing utility may require you to further define these trace
The dynamic tracing utility might require you to further define these trace
points. For example, DTrace requires you to add new probes to the file
<filename>src/backend/utils/probes.d</> as shown here:
<programlisting>
......
doc/src/sgml/mvcc.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/mvcc.sgml,v 2.65 2006/12/01 01:04:36 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/mvcc.sgml,v 2.66 2007/01/31 20:56:18 momjian Exp $ -->
<chapter id="mvcc">
<title>Concurrency Control</title>
......@@ -215,7 +215,7 @@
Committed and Serializable. When you select the level Read
Uncommitted you really get Read Committed, and when you select
Repeatable Read you really get Serializable, so the actual
isolation level may be stricter than what you select. This is
isolation level might be stricter than what you select. This is
permitted by the SQL standard: the four isolation levels only
define which phenomena must not happen, they do not define which
phenomena must happen. The reason that <productname>PostgreSQL</>
......@@ -261,7 +261,7 @@
behave the same as <command>SELECT</command>
in terms of searching for target rows: they will only find target rows
that were committed as of the command start time. However, such a target
row may have already been updated (or deleted or locked) by
row might have already been updated (or deleted or locked) by
another concurrent transaction by the time it is found. In this case, the
would-be updater will wait for the first updating transaction to commit or
roll back (if it is still in progress). If the first updater rolls back,
......@@ -314,7 +314,7 @@ COMMIT;
<para>
The partial transaction isolation provided by Read Committed mode is
adequate for many applications, and this mode is fast and simple to use.
However, for applications that do complex queries and updates, it may
However, for applications that do complex queries and updates, it might
be necessary to guarantee a more rigorously consistent view of the
database than the Read Committed mode provides.
</para>
......@@ -359,7 +359,7 @@ COMMIT;
in terms of searching for target rows: they will only find target rows
that were committed as of the transaction start time. However, such a
target
row may have already been updated (or deleted or locked) by
row might have already been updated (or deleted or locked) by
another concurrent transaction by the time it is found. In this case, the
serializable transaction will wait for the first updating transaction to commit or
roll back (if it is still in progress). If the first updater rolls back,
......@@ -386,7 +386,7 @@ ERROR: could not serialize access due to concurrent update
</para>
<para>
Note that only updating transactions may need to be retried; read-only
Note that only updating transactions might need to be retried; read-only
transactions will never have serialization conflicts.
</para>
......@@ -395,9 +395,9 @@ ERROR: could not serialize access due to concurrent update
transaction sees a wholly consistent view of the database. However,
the application has to be prepared to retry transactions when concurrent
updates make it impossible to sustain the illusion of serial execution.
Since the cost of redoing complex transactions may be significant,
Since the cost of redoing complex transactions might be significant,
this mode is recommended only when updating transactions contain logic
sufficiently complex that they may give wrong answers in Read
sufficiently complex that they might give wrong answers in Read
Committed mode. Most commonly, Serializable mode is necessary when
a transaction executes several successive commands that must see
identical views of the database.
......@@ -418,7 +418,7 @@ ERROR: could not serialize access due to concurrent update
The intuitive meaning (and mathematical definition) of
<quote>serializable</> execution is that any two successfully committed
concurrent transactions will appear to have executed strictly serially,
one after the other &mdash; although which one appeared to occur first may
one after the other &mdash; although which one appeared to occur first might
not be predictable in advance. It is important to realize that forbidding
the undesirable behaviors listed in <xref linkend="mvcc-isolevel-table">
is not sufficient to guarantee true serializability, and in fact
......@@ -538,10 +538,10 @@ SELECT SUM(value) FROM mytab WHERE class = 2;
between one lock mode and another is the set of lock modes with
which each conflicts. Two transactions cannot hold locks of conflicting
modes on the same table at the same time. (However, a transaction
never conflicts with itself. For example, it may acquire
never conflicts with itself. For example, it might acquire
<literal>ACCESS EXCLUSIVE</literal> lock and later acquire
<literal>ACCESS SHARE</literal> lock on the same table.) Non-conflicting
lock modes may be held concurrently by many transactions. Notice in
lock modes can be held concurrently by many transactions. Notice in
particular that some lock modes are self-conflicting (for example,
an <literal>ACCESS EXCLUSIVE</literal> lock cannot be held by more than one
transaction at a time) while others are not self-conflicting (for example,
......@@ -760,7 +760,7 @@ SELECT SUM(value) FROM mytab WHERE class = 2;
To acquire an exclusive row-level lock on a row without actually
modifying the row, select the row with <command>SELECT FOR
UPDATE</command>. Note that once the row-level lock is acquired,
the transaction may update the row multiple times without
the transaction can update the row multiple times without
fear of conflicts.
</para>
......@@ -777,7 +777,7 @@ SELECT SUM(value) FROM mytab WHERE class = 2;
<productname>PostgreSQL</productname> doesn't remember any
information about modified rows in memory, so it has no limit to
the number of rows locked at one time. However, locking a row
may cause a disk write; thus, for example, <command>SELECT FOR
might cause a disk write; thus, for example, <command>SELECT FOR
UPDATE</command> will modify selected rows to mark them locked, and so
will result in disk writes.
</para>
......@@ -863,7 +863,7 @@ UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 22222;
occurred. One should also ensure that the first lock acquired on
an object in a transaction is the highest mode that will be
needed for that object. If it is not feasible to verify this in
advance, then deadlocks may be handled on-the-fly by retrying
advance, then deadlocks can be handled on-the-fly by retrying
transactions that are aborted due to deadlock.
</para>
......@@ -977,12 +977,12 @@ SELECT pg_advisory_lock(q.id) FROM
<para>
Another way to think about it is that each
transaction sees a snapshot of the database contents, and concurrently
executing transactions may very well see different snapshots. So the
executing transactions might very well see different snapshots. So the
whole concept of <quote>now</quote> is somewhat ill-defined anyway.
This is not normally
a big problem if the client applications are isolated from each other,
but if the clients can communicate via channels outside the database
then serious confusion may ensue.
then serious confusion might ensue.
</para>
<para>
......@@ -1026,7 +1026,7 @@ SELECT pg_advisory_lock(q.id) FROM
lock(s) before performing queries. A lock obtained by a
serializable transaction guarantees that no other transactions modifying
the table are still running, but if the snapshot seen by the
transaction predates obtaining the lock, it may predate some now-committed
transaction predates obtaining the lock, it might predate some now-committed
changes in the table. A serializable transaction's snapshot is actually
frozen at the start of its first query or data-modification command
(<literal>SELECT</>, <literal>INSERT</>,
......@@ -1092,7 +1092,7 @@ SELECT pg_advisory_lock(q.id) FROM
read/write access. Locks are released immediately after each
index row is fetched or inserted. But note that a GIN-indexed
value insertion usually produces several index key insertions
per row, so GIN may do substantial work for a single value's
per row, so GIN might do substantial work for a single value's
insertion.
</para>
</listitem>
......
doc/src/sgml/nls.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/nls.sgml,v 1.14 2006/03/10 19:10:48 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/nls.sgml,v 1.15 2007/01/31 20:56:18 momjian Exp $ -->
<chapter id="nls">
<chapterinfo>
......@@ -108,7 +108,7 @@ msgstr "another translated"
<para>
The # character introduces a comment. If whitespace immediately
follows the # character, then this is a comment maintained by the
translator. There may also be automatic comments, which have a
translator. There can also be automatic comments, which have a
non-whitespace character immediately following the #. These are
maintained by the various tools that operate on the PO files and
are intended to aid the translator.
......@@ -157,7 +157,7 @@ msgstr "another translated"
ISO 639-1 two-letter language code (in lower case)</ulink>, e.g.,
<filename>fr.po</filename> for French. If there is really a need
for more than one translation effort per language then the files
may also be named
can also be named
<filename><replaceable>language</replaceable>_<replaceable>region</replaceable>.po</filename>
where <replaceable>region</replaceable> is the
<ulink url="http://www.din.de/gremien/nas/nabd/iso3166ma/codlstp1/en_listp1.html">
......@@ -187,11 +187,11 @@ gmake init-po
<programlisting>
AVAIL_LANGUAGES := de fr
</programlisting>
(Other languages may appear, of course.)
(Other languages can appear, of course.)
</para>
<para>
As the underlying program or library changes, messages may be
As the underlying program or library changes, messages might be
changed or added by the programmers. In this case you do not need
to start from scratch. Instead, run the command
<programlisting>
......@@ -212,7 +212,7 @@ gmake update-po
<para>
The PO files can be edited with a regular text editor. The
translator should only change the area between the quotes after
the msgstr directive, may add comments and alter the fuzzy flag.
the msgstr directive, add comments, and alter the fuzzy flag.
There is (unsurprisingly) a PO mode for Emacs, which I find quite
useful.
</para>
......@@ -255,7 +255,7 @@ msgstr "Die Datei %2$s hat %1$u Zeichen."
<literal><replaceable>digits</replaceable>$</literal> needs to
follow the % immediately, before any other format manipulators.
(This feature really exists in the <function>printf</function>
family of functions. You may not have heard of it before because
family of functions. You might not have heard of it before because
there is little use for it outside of message
internationalization.)
</para>
......@@ -268,7 +268,7 @@ msgstr "Die Datei %2$s hat %1$u Zeichen."
normally. The corrected string can be merged in when the
program sources have been updated. If the original string
contains a factual mistake, report that (or fix it yourself)
and do not translate it. Instead, you may mark the string with
and do not translate it. Instead, you can mark the string with
a comment in the PO file.
</para>
</listitem>
......@@ -280,7 +280,7 @@ msgstr "Die Datei %2$s hat %1$u Zeichen."
open file %s</literal>) should probably not start with a
capital letter (if your language distinguishes letter case) or
end with a period (if your language uses punctuation marks).
It may help to read <xref linkend="error-style-guide">.
It might help to read <xref linkend="error-style-guide">.
</para>
</listitem>
......@@ -353,7 +353,7 @@ fprintf(stderr, gettext("panic level %d\n"), lvl);
</para>
<para>
This may tend to add a lot of clutter. One common shortcut is to use
This tends to add a lot of clutter. One common shortcut is to use
<programlisting>
#define _(x) gettext(x)
</programlisting>
......@@ -451,9 +451,9 @@ fprintf(stderr, gettext("panic level %d\n"), lvl);
<programlisting>
printf("Files were %s.\n", flag ? "copied" : "removed");
</programlisting>
The word order within the sentence may be different in other
The word order within the sentence might be different in other
languages. Also, even if you remember to call gettext() on each
fragment, the fragments may not translate well separately. It's
fragment, the fragments might not translate well separately. It's
better to duplicate a little code so that each message to be
translated is a coherent whole. Only numbers, file names, and
such-like run-time variables should be inserted at run time into
......@@ -476,7 +476,7 @@ else
printf("copied %d files", n):
</programlisting>
then be disappointed. Some languages have more than two forms,
with some peculiar rules. We may have a solution for this in
with some peculiar rules. We might have a solution for this in
the future, but for now the matter is best avoided altogether.
You could write:
<programlisting>
......
doc/src/sgml/perform.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.60 2007/01/25 02:17:25 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.61 2007/01/31 20:56:18 momjian Exp $ -->
<chapter id="performance-tips">
<title>Performance Tips</title>
......@@ -90,7 +90,7 @@ EXPLAIN SELECT * FROM tenk1;
<listitem>
<para>
Estimated total cost (If all rows were to be retrieved, which they may
Estimated total cost (If all rows were to be retrieved, though they might
not be: for example, a query with a <literal>LIMIT</> clause will stop
short of paying the total cost of the <literal>Limit</> plan node's
input node.)
......@@ -230,7 +230,7 @@ EXPLAIN SELECT * FROM tenk1 WHERE unique1 &lt; 100;
</para>
<para>
If the <literal>WHERE</> condition is selective enough, the planner may
If the <literal>WHERE</> condition is selective enough, the planner might
switch to a <quote>simple</> index scan plan:
<programlisting>
......@@ -426,7 +426,7 @@ EXPLAIN ANALYZE SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 &lt; 100 AND t
run time will normally be just a little larger than the total time
reported for the top-level plan node. For <command>INSERT</>,
<command>UPDATE</>, and <command>DELETE</> commands, the total run time
may be considerably larger, because it includes the time spent processing
might be considerably larger, because it includes the time spent processing
the result rows. In these commands, the time for the top plan node
essentially is the time spent computing the new rows and/or locating the
old ones, but it doesn't include the time spent applying the changes.
......@@ -438,7 +438,7 @@ EXPLAIN ANALYZE SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 &lt; 100 AND t
It is worth noting that <command>EXPLAIN</> results should not be extrapolated
to situations other than the one you are actually testing; for example,
results on a toy-sized table can't be assumed to apply to large tables.
The planner's cost estimates are not linear and so it may well choose
The planner's cost estimates are not linear and so it might choose
a different plan for a larger or smaller table. An extreme example
is that on a table that only occupies one disk page, you'll nearly
always get a sequential scan plan whether indexes are available or not.
......@@ -564,10 +564,10 @@ SELECT attname, n_distinct, most_common_vals FROM pg_stats WHERE tablename = 'ro
command, or globally by setting the
<xref linkend="guc-default-statistics-target"> configuration variable.
The default limit is presently 10 entries. Raising the limit
may allow more accurate planner estimates to be made, particularly for
might allow more accurate planner estimates to be made, particularly for
columns with irregular data distributions, at the price of consuming
more space in <structname>pg_statistic</structname> and slightly more
time to compute the estimates. Conversely, a lower limit may be
time to compute the estimates. Conversely, a lower limit might be
appropriate for columns with simple data distributions.
</para>
......@@ -605,7 +605,7 @@ SELECT * FROM a, b, c WHERE a.id = b.id AND b.ref = c.id;
between two input tables, so it's necessary to build up the result
in one or another of these fashions.) The important point is that
these different join possibilities give semantically equivalent
results but may have hugely different execution costs. Therefore,
results but might have hugely different execution costs. Therefore,
the planner will explore all of them to try to find the most
efficient query plan.
</para>
......@@ -615,7 +615,7 @@ SELECT * FROM a, b, c WHERE a.id = b.id AND b.ref = c.id;
orders to worry about. But the number of possible join orders grows
exponentially as the number of tables expands. Beyond ten or so input
tables it's no longer practical to do an exhaustive search of all the
possibilities, and even for six or seven tables planning may take an
possibilities, and even for six or seven tables planning might take an
annoyingly long time. When there are too many input tables, the
<productname>PostgreSQL</productname> planner will switch from exhaustive
search to a <firstterm>genetic</firstterm> probabilistic search
......@@ -638,7 +638,7 @@ SELECT * FROM a LEFT JOIN (b JOIN c ON (b.ref = c.id)) ON (a.id = b.id);
Therefore the planner has no choice of join order here: it must join
B to C and then join A to that result. Accordingly, this query takes
less time to plan than the previous query. In other cases, the planner
may be able to determine that more than one join order is safe.
might be able to determine that more than one join order is safe.
For example, given
<programlisting>
SELECT * FROM a LEFT JOIN b ON (a.bid = b.id) LEFT JOIN c ON (a.cid = c.id);
......@@ -751,7 +751,7 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
<title>Populating a Database</title>
<para>
One may need to insert a large amount of data when first populating
One might need to insert a large amount of data when first populating
a database. This section contains some suggestions on how to make
this process as efficient as possible.
</para>
......@@ -767,7 +767,7 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
<para>
Turn off autocommit and just do one commit at the end. (In plain
SQL, this means issuing <command>BEGIN</command> at the start and
<command>COMMIT</command> at the end. Some client libraries may
<command>COMMIT</command> at the end. Some client libraries might
do this behind your back, in which case you need to make sure the
library does it when you want it done.) If you allow each
insertion to be committed separately,
......@@ -795,7 +795,7 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
</para>
<para>
If you cannot use <command>COPY</command>, it may help to use <xref
If you cannot use <command>COPY</command>, it might help to use <xref
linkend="sql-prepare" endterm="sql-prepare-title"> to create a
prepared <command>INSERT</command> statement, and then use
<command>EXECUTE</command> as many times as required. This avoids
......@@ -840,9 +840,9 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
<para>
If you are adding large amounts of data to an existing table,
it may be a win to drop the index,
it might be a win to drop the index,
load the table, and then recreate the index. Of course, the
database performance for other users may be adversely affected
database performance for other users might be adversely affected
during the time that the index is missing. One should also think
twice before dropping unique indexes, since the error checking
afforded by the unique constraint will be lost while the index is
......@@ -855,7 +855,7 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
<para>
Just as with indexes, a foreign key constraint can be checked
<quote>in bulk</> more efficiently than row-by-row. So it may be
<quote>in bulk</> more efficiently than row-by-row. So it might be
useful to drop foreign key constraints, load data, and re-create
the constraints. Again, there is a trade-off between data load
speed and loss of error checking while the constraint is missing.
......@@ -897,8 +897,8 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
<title>Turn off <varname>archive_command</varname></title>
<para>
When loading large amounts of data you may want to unset the
<xref linkend="guc-archive-command"> before loading. It may be
When loading large amounts of data you might want to unset the
<xref linkend="guc-archive-command"> before loading. It might be
faster to take a new base backup once the load has completed
than to allow a large archive to accumulate.
</para>
......@@ -926,7 +926,7 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
includes bulk loading large amounts of data into the table. Running
<command>ANALYZE</command> (or <command>VACUUM ANALYZE</command>)
ensures that the planner has up-to-date statistics about the
table. With no statistics or obsolete statistics, the planner may
table. With no statistics or obsolete statistics, the planner might
make poor decisions during query planning, leading to poor
performance on any tables with inaccurate or nonexistent
statistics.
......
doc/src/sgml/planstats.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/planstats.sgml,v 1.7 2006/09/16 00:30:14 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/planstats.sgml,v 1.8 2007/01/31 20:56:18 momjian Exp $ -->
<chapter id="planner-stats-details">
<title>How the Planner Uses Statistics</title>
......@@ -21,7 +21,7 @@
<para>
The outputs and algorithms shown below are taken from version 8.0.
The behavior of earlier (or later) versions may vary.
The behavior of earlier (or later) versions might vary.
</para>
<sect1 id="row-estimation-examples">
......@@ -56,7 +56,7 @@ SELECT reltuples, relpages FROM pg_class WHERE relname = 'tenk1';
345 | 10000
</programlisting>
The planner will check the <structfield>relpages</structfield>
estimate (this is a cheap operation) and if incorrect may scale
estimate (this is a cheap operation) and if incorrect might scale
<structfield>reltuples</structfield> to obtain a row estimate. In this
case it does not, thus:
......
doc/src/sgml/plperl.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/plperl.sgml,v 2.60 2007/01/30 22:29:23 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/plperl.sgml,v 2.61 2007/01/31 20:56:18 momjian Exp $ -->
<chapter id="plperl">
<title>PL/Perl - Perl Procedural Language</title>
......@@ -20,7 +20,7 @@
<para> The usual advantage to using PL/Perl is that this allows use,
within stored functions, of the manyfold <quote>string
munging</quote> operators and functions available for Perl. Parsing
complex strings may be be easier using Perl than it is with the
complex strings might be be easier using Perl than it is with the
string functions and control structures provided in PL/pgSQL.</para>
<para>
......@@ -382,7 +382,7 @@ SELECT * FROM test_munge();
</para>
<para>
<literal>spi_query</literal> and <literal>spi_fetchrow</literal>
work together as a pair for row sets which may be large, or for cases
work together as a pair for row sets which might be large, or for cases
where you wish to return rows as they arrive.
<literal>spi_fetchrow</literal> works <emphasis>only</emphasis> with
<literal>spi_query</literal>. The following example illustrates how
......@@ -429,7 +429,7 @@ SELECT * from lotsa_md5(500);
<para>
The advantage of prepared queries is that is it possible to use one prepared plan for more
than one query execution. After the plan is not needed anymore, it may be freed with
than one query execution. After the plan is not needed anymore, it can be freed with
<literal>spi_freeplan</literal>:
</para>
......@@ -601,7 +601,7 @@ $$ LANGUAGE plperl;
external modules). There is no way to access internals of the
database server process or to gain OS-level access with the
permissions of the server process,
as a C function can do. Thus, any unprivileged database user may
as a C function can do. Thus, any unprivileged database user can
be permitted to use this language.
</para>
......
doc/src/sgml/plpgsql.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.103 2007/01/30 22:29:23 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.104 2007/01/31 20:56:18 momjian Exp $ -->
<chapter id="plpgsql">
<title><application>PL/pgSQL</application> - <acronym>SQL</acronym> Procedural Language</title>
......@@ -84,7 +84,7 @@
substantially reduce the total amount of time required to parse
and generate execution plans for the statements in a
<application>PL/pgSQL</> function. A disadvantage is that errors
in a specific expression or command may not be detected until that
in a specific expression or command cannot be detected until that
part of the function is reached in execution.
</para>
......@@ -208,7 +208,7 @@ $$ LANGUAGE plpgsql;
</para>
<para>
<application>PL/pgSQL</> functions may also be declared to accept
<application>PL/pgSQL</> functions can also be declared to accept
and return the polymorphic types
<type>anyelement</type> and <type>anyarray</type>. The actual
data types handled by a polymorphic function can vary from call to
......@@ -224,7 +224,7 @@ $$ LANGUAGE plpgsql;
</para>
<para>
Finally, a <application>PL/pgSQL</> function may be declared to return
Finally, a <application>PL/pgSQL</> function can be declared to return
<type>void</> if it has no useful return value.
</para>
......@@ -313,7 +313,7 @@ $PROC$ LANGUAGE plpgsql;
<para>
The following chart shows what you have to do when writing quote
marks without dollar quoting. It may be useful when translating
marks without dollar quoting. It might be useful when translating
pre-dollar quoting code into something more comprehensible.
</para>
......@@ -766,13 +766,13 @@ user_id users.user_id%TYPE;
type of the structure you are referencing, and most importantly,
if the data type of the referenced item changes in the future (for
instance: you change the type of <literal>user_id</>
from <type>integer</type> to <type>real</type>), you may not need
from <type>integer</type> to <type>real</type>), you might not need
to change your function definition.
</para>
<para>
<literal>%TYPE</literal> is particularly valuable in polymorphic
functions, since the data types needed for internal variables may
functions, since the data types needed for internal variables can
change from one call to the next. Appropriate variables can be
created by applying <literal>%TYPE</literal> to the function's
arguments or result placeholders.
......@@ -866,7 +866,7 @@ SELECT merge_fields(t.*) FROM table1 t WHERE ... ;
Note that <literal>RECORD</> is not a true data type, only a placeholder.
One should also realize that when a <application>PL/pgSQL</application>
function is declared to return type <type>record</>, this is not quite the
same concept as a record variable, even though such a function may well
same concept as a record variable, even though such a function might
use a record variable to hold its result. In both cases the actual row
structure is unknown when the function is written, but for a function
returning <type>record</> the actual structure is determined when the
......@@ -1530,7 +1530,7 @@ GET DIAGNOSTICS integer_var = ROW_COUNT;
loops). <literal>FOUND</literal> is set this way when the
<command>FOR</> loop exits; inside the execution of the loop,
<literal>FOUND</literal> is not modified by the
<command>FOR</> statement, although it may be changed by the
<command>FOR</> statement, although it might be changed by the
execution of other statements within the loop body.
</para>
</listitem>
......@@ -1671,10 +1671,10 @@ SELECT * FROM some_func();
for <application>PL/pgSQL</> stores the entire result set
before returning from the function, as discussed above. That
means that if a <application>PL/pgSQL</> function produces a
very large result set, performance may be poor: data will be
very large result set, performance might be poor: data will be
written to disk to avoid memory exhaustion, but the function
itself will not return until the entire result set has been
generated. A future version of <application>PL/pgSQL</> may
generated. A future version of <application>PL/pgSQL</> might
allow users to define set-returning functions
that do not have this limitation. Currently, the point at
which data begins being written to disk is controlled by the
......@@ -2364,7 +2364,7 @@ SELECT merge_db(1, 'dennis');
<synopsis>
<replaceable>name</replaceable> CURSOR <optional> ( <replaceable>arguments</replaceable> ) </optional> FOR <replaceable>query</replaceable>;
</synopsis>
(<literal>FOR</> may be replaced by <literal>IS</> for
(<literal>FOR</> can be replaced by <literal>IS</> for
<productname>Oracle</productname> compatibility.)
<replaceable>arguments</replaceable>, if specified, is a
comma-separated list of pairs <literal><replaceable>name</replaceable>
......@@ -2382,7 +2382,7 @@ DECLARE
curs3 CURSOR (key integer) IS SELECT * FROM tenk1 WHERE unique1 = key;
</programlisting>
All three of these variables have the data type <type>refcursor</>,
but the first may be used with any query, while the second has
but the first can be used with any query, while the second has
a fully specified query already <firstterm>bound</> to it, and the last
has a parameterized query bound to it. (<literal>key</> will be
replaced by an integer parameter value when the cursor is opened.)
......@@ -2516,10 +2516,10 @@ FETCH <replaceable>cursor</replaceable> INTO <replaceable>target</replaceable>;
<para>
<command>FETCH</command> retrieves the next row from the
cursor into a target, which may be a row variable, a record
cursor into a target, which might be a row variable, a record
variable, or a comma-separated list of simple variables, just like
<command>SELECT INTO</command>. As with <command>SELECT
INTO</command>, the special variable <literal>FOUND</literal> may
INTO</command>, the special variable <literal>FOUND</literal> can
be checked to see whether a row was obtained or not.
</para>
......@@ -2902,7 +2902,7 @@ RAISE EXCEPTION 'Nonexistent ID --> %', user_id;
</para>
<para>
Row-level triggers fired <literal>BEFORE</> may return null to signal the
Row-level triggers fired <literal>BEFORE</> can return null to signal the
trigger manager to skip the rest of the operation for this row
(i.e., subsequent triggers are not fired, and the
<command>INSERT</>/<command>UPDATE</>/<command>DELETE</> does not occur
......@@ -2919,8 +2919,8 @@ RAISE EXCEPTION 'Nonexistent ID --> %', user_id;
<para>
The return value of a <literal>BEFORE</> or <literal>AFTER</>
statement-level trigger or an <literal>AFTER</> row-level trigger is
always ignored; it may as well be null. However, any of these types of
triggers can still abort the entire operation by raising an error.
always ignored; it might as well be null. However, any of these types of
triggers might still abort the entire operation by raising an error.
</para>
<para>
......@@ -3037,7 +3037,7 @@ AFTER INSERT OR UPDATE OR DELETE ON emp
original table for certain queries &mdash; often with vastly reduced run
times.
This technique is commonly used in Data Warehousing, where the tables
of measured or observed data (called fact tables) can be extremely large.
of measured or observed data (called fact tables) might be extremely large.
<xref linkend="plpgsql-trigger-summary-example"> shows an example of a
trigger procedure in <application>PL/pgSQL</application> that maintains
a summary table for a fact table in a data warehouse.
......
doc/src/sgml/plpython.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/plpython.sgml,v 1.36 2006/10/23 18:10:31 petere Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/plpython.sgml,v 1.37 2007/01/31 20:56:18 momjian Exp $ -->
<chapter id="plpython">
<title>PL/Python - Python Procedural Language</title>
......@@ -29,7 +29,7 @@
available as an <quote>untrusted</> language (meaning it does not
offer any way of restricting what users can do in it). It has
therefore been renamed to <literal>plpythonu</>. The trusted
variant <literal>plpython</> may become available again in future,
variant <literal>plpython</> might become available again in future,
if a new secure execution mechanism is developed in Python.
</para>
......@@ -401,7 +401,7 @@ $$ LANGUAGE plpythonu;
</para>
<para>
If <literal>TD["when"]</literal> is <literal>BEFORE</>, you may
If <literal>TD["when"]</literal> is <literal>BEFORE</>, you can
return <literal>None</literal> or <literal>"OK"</literal> from the
Python function to indicate the row is unmodified,
<literal>"SKIP"</> to abort the event, or <literal>"MODIFY"</> to
......
doc/src/sgml/pltcl.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/pltcl.sgml,v 2.43 2007/01/30 22:29:23 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/pltcl.sgml,v 2.44 2007/01/31 20:56:18 momjian Exp $ -->
<chapter id="pltcl">
<title>PL/Tcl - Tcl Procedural Language</title>
......@@ -39,12 +39,12 @@
provides no way to access internals of the database server or to
gain OS-level access under the permissions of the
<productname>PostgreSQL</productname> server process, as a C
function can do. Thus, unprivileged database users may be trusted
function can do. Thus, unprivileged database users can be trusted
to use this language; it does not give them unlimited authority.
</para>
<para>
The other notable implementation restriction is that Tcl functions
may not be used to create input/output functions for new data
cannot be used to create input/output functions for new data
types.
</para>
<para>
......@@ -325,7 +325,7 @@ spi_exec -array C "SELECT * FROM pg_class" {
PL/Tcl</></>
</para>
<para>
The query may use parameters, that is, placeholders for
The query can use parameters, that is, placeholders for
values to be supplied whenever the plan is actually executed.
In the query string, refer to parameters
by the symbols <literal>$1</literal> ... <literal>$<replaceable>n</replaceable></literal>.
......@@ -417,7 +417,7 @@ $$ LANGUAGE pltcl;
<listitem>
<para>
Doubles all occurrences of single quote and backslash characters
in the given string. This may be used to safely quote strings
in the given string. This can be used to safely quote strings
that are to be inserted into SQL commands given
to <function>spi_exec</function> or
<function>spi_prepare</function>.
......@@ -726,9 +726,8 @@ CREATE TRIGGER trig_mytab_modcount BEFORE INSERT OR UPDATE ON mytab
<title>Tcl Procedure Names</title>
<para>
In <productname>PostgreSQL</productname>, one and the
same function name can be used for
different functions as long as the number of arguments or their types
In <productname>PostgreSQL</productname>, the same function name can be used for
different function definitions as long as the number of arguments or their types
differ. Tcl, however, requires all procedure names to be distinct.
PL/Tcl deals with this by making the internal Tcl procedure names contain
the object
......
doc/src/sgml/postgres.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/postgres.sgml,v 1.80 2006/11/17 16:38:44 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/postgres.sgml,v 1.81 2007/01/31 20:56:18 momjian Exp $ -->
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.2//EN" [
......@@ -223,7 +223,7 @@
<partintro>
<para>
This part contains assorted information that can be of use to
This part contains assorted information that might be of use to
<productname>PostgreSQL</> developers.
</para>
</partintro>
......
doc/src/sgml/problems.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/problems.sgml,v 2.27 2006/09/16 00:30:15 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/problems.sgml,v 2.28 2007/01/31 20:56:18 momjian Exp $ -->
<sect1 id="bug-reporting">
<title>Bug Reporting Guidelines</title>
......@@ -228,7 +228,7 @@
If the function or the options do not exist then your version is
more than old enough to warrant an upgrade.
If you run a prepackaged version, such as RPMs, say so, including any
subversion the package may have. If you are talking about a CVS
subversion the package might have. If you are talking about a CVS
snapshot, mention that, including its date and time.
</para>
......
doc/src/sgml/protocol.sgml
View file @ a134ee33
This diff is collapsed.
doc/src/sgml/queries.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/queries.sgml,v 1.41 2007/01/09 16:59:20 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/queries.sgml,v 1.42 2007/01/31 20:56:18 momjian Exp $ -->
<chapter id="queries">
<title>Queries</title>
......@@ -116,11 +116,11 @@ SELECT random();
FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_reference</replaceable> <optional>, ...</optional></optional>
</synopsis>
A table reference may be a table name (possibly schema-qualified),
A table reference can be a table name (possibly schema-qualified),
or a derived table such as a subquery, a table join, or complex
combinations of these. If more than one table reference is listed
in the <literal>FROM</> clause they are cross-joined (see below)
to form the intermediate virtual table that may then be subject to
to form the intermediate virtual table that can then be subject to
transformations by the <literal>WHERE</>, <literal>GROUP BY</>,
and <literal>HAVING</> clauses and is finally the result of the
overall table expression.
......@@ -350,8 +350,8 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r
<para>
Joins of all types can be chained together or nested: either or
both of <replaceable>T1</replaceable> and
<replaceable>T2</replaceable> may be joined tables. Parentheses
may be used around <literal>JOIN</> clauses to control the join
<replaceable>T2</replaceable> might be joined tables. Parentheses
can be used around <literal>JOIN</> clauses to control the join
order. In the absence of parentheses, <literal>JOIN</> clauses
nest left-to-right.
</para>
......@@ -623,7 +623,7 @@ FROM (VALUES ('anne', 'smith'), ('bob', 'jones'), ('joe', 'blow'))
of either base data types (scalar types) or composite data types
(table rows). They are used like a table, view, or subquery in
the <literal>FROM</> clause of a query. Columns returned by table
functions may be included in <literal>SELECT</>,
functions can be included in <literal>SELECT</>,
<literal>JOIN</>, or <literal>WHERE</> clauses in the same manner
as a table, view, or subquery column.
</para>
......@@ -636,8 +636,8 @@ FROM (VALUES ('anne', 'smith'), ('bob', 'jones'), ('joe', 'blow'))
</para>
<para>
A table function may be aliased in the <literal>FROM</> clause,
but it also may be left unaliased. If a function is used in the
A table function can be aliased in the <literal>FROM</> clause,
but it also can be left unaliased. If a function is used in the
<literal>FROM</> clause with no alias, the function name is used
as the resulting table name.
</para>
......@@ -788,7 +788,7 @@ SELECT ... FROM fdt WHERE EXISTS (SELECT c1 FROM t2 WHERE c2 &gt; fdt.c1)
<para>
After passing the <literal>WHERE</> filter, the derived input
table may be subject to grouping, using the <literal>GROUP BY</>
table might be subject to grouping, using the <literal>GROUP BY</>
clause, and elimination of group rows using the <literal>HAVING</>
clause.
</para>
......@@ -877,7 +877,7 @@ SELECT product_id, p.name, (sum(s.units) * p.price) AS sales
<literal>p.name</literal>, and <literal>p.price</literal> must be
in the <literal>GROUP BY</> clause since they are referenced in
the query select list. (Depending on how exactly the products
table is set up, name and price may be fully dependent on the
table is set up, name and price might be fully dependent on the
product ID, so the additional groupings could theoretically be
unnecessary, but this is not implemented yet.) The column
<literal>s.units</> does not have to be in the <literal>GROUP
......@@ -1070,7 +1070,7 @@ SELECT a AS value, b + c AS sum FROM ...
</indexterm>
<para>
After the select list has been processed, the result table may
After the select list has been processed, the result table can
optionally be subject to the elimination of duplicate rows. The
<literal>DISTINCT</literal> key word is written directly after
<literal>SELECT</literal> to specify this:
......@@ -1234,7 +1234,7 @@ SELECT a, b FROM table1 ORDER BY a + b, c;
</programlisting>
When more than one expression is specified,
the later values are used to sort rows that are equal according to the
earlier values. Each expression may be followed by an optional
earlier values. Each expression can be followed by an optional
<literal>ASC</> or <literal>DESC</> keyword to set the sort direction to
ascending or descending. <literal>ASC</> order is the default.
Ascending order puts smaller values first, where
......@@ -1342,7 +1342,7 @@ SELECT <replaceable>select_list</replaceable>
When using <literal>LIMIT</>, it is important to use an
<literal>ORDER BY</> clause that constrains the result rows into a
unique order. Otherwise you will get an unpredictable subset of
the query's rows. You may be asking for the tenth through
the query's rows. You might be asking for the tenth through
twentieth rows, but tenth through twentieth in what ordering? The
ordering is unknown, unless you specified <literal>ORDER BY</>.
</para>
......@@ -1364,7 +1364,7 @@ SELECT <replaceable>select_list</replaceable>
<para>
The rows skipped by an <literal>OFFSET</> clause still have to be
computed inside the server; therefore a large <literal>OFFSET</>
can be inefficient.
might be inefficient.
</para>
</sect1>
......
doc/src/sgml/query.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/query.sgml,v 1.48 2006/10/21 23:12:57 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/query.sgml,v 1.49 2007/01/31 20:56:18 momjian Exp $ -->
<chapter id="tutorial-sql">
<title>The <acronym>SQL</acronym> Language</title>
......@@ -134,7 +134,7 @@ CREATE TABLE weather (
</para>
<para>
White space (i.e., spaces, tabs, and newlines) may be used freely
White space (i.e., spaces, tabs, and newlines) can be used freely
in SQL commands. That means you can type the command aligned
differently than above, or even all on one line. Two dashes
(<quote><literal>--</literal></quote>) introduce comments.
......@@ -151,7 +151,7 @@ CREATE TABLE weather (
a type for storing single precision floating-point numbers.
<type>date</type> should be self-explanatory. (Yes, the column of
type <type>date</type> is also named <literal>date</literal>.
This may be convenient or confusing &mdash; you choose.)
This might be convenient or confusing &mdash; you choose.)
</para>
<para>
......@@ -817,7 +817,7 @@ SELECT city, max(temp_lo)
You can update existing rows using the
<command>UPDATE</command> command.
Suppose you discover the temperature readings are
all off by 2 degrees after November 28. You may correct the
all off by 2 degrees after November 28. You can correct the
data as follows:
<programlisting>
......
doc/src/sgml/reference.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/reference.sgml,v 1.61 2007/01/23 05:07:17 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/reference.sgml,v 1.62 2007/01/31 20:56:18 momjian Exp $ -->
<part id="reference">
<title>Reference</title>
......@@ -9,7 +9,7 @@
length an authoritative, complete, and formal summary about their
respective subjects. More information about the use of
<productname>PostgreSQL</productname>, in narrative, tutorial, or
example form, may be found in other parts of this book. See the
example form, can be found in other parts of this book. See the
cross-references listed on each reference page.
</para>
......@@ -159,7 +159,7 @@
This part contains reference information for
<productname>PostgreSQL</productname> client applications and
utilities. Not all of these commands are of general utility, some
may require special privileges. The common feature of these
might require special privileges. The common feature of these
applications is that they can be run on any host, independent of
where the database server resides.
</para>
......
doc/src/sgml/regress.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/regress.sgml,v 1.55 2006/09/16 00:30:15 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/regress.sgml,v 1.56 2007/01/31 20:56:18 momjian Exp $ -->
<chapter id="regress">
<title id="regress-title">Regression Tests</title>
......@@ -84,7 +84,7 @@ gmake check
If you have configured <productname>PostgreSQL</productname> to install
into a location where an older <productname>PostgreSQL</productname>
installation already exists, and you perform <literal>gmake check</>
before installing the new version, you may find that the tests fail
before installing the new version, you might find that the tests fail
because the new programs try to use the already-installed shared
libraries. (Typical symptoms are complaints about undefined symbols.)
If you wish to run the tests before overwriting the old installation,
......@@ -99,7 +99,7 @@ gmake check
scripts, which means forty processes: there's a server process and a
<application>psql</> process for each test script.
So if your system enforces a per-user limit on the number of processes,
make sure this limit is at least fifty or so, else you may get
make sure this limit is at least fifty or so, else you might get
random-seeming failures in the parallel test. If you are not in
a position to raise the limit, you can cut down the degree of parallelism
by setting the <literal>MAX_CONNECTIONS</> parameter. For example,
......@@ -161,7 +161,7 @@ gmake installcheck
generated on a reference system, so the results are sensitive to
small system differences. When a test is reported as
<quote>failed</quote>, always examine the differences between
expected and actual results; you may well find that the
expected and actual results; you might find that the
differences are not significant. Nonetheless, we still strive to
maintain accurate reference files across all supported platforms,
so it can be expected that all tests pass.
......@@ -193,7 +193,7 @@ gmake installcheck
Some of the regression tests involve intentional invalid input
values. Error messages can come from either the
<productname>PostgreSQL</productname> code or from the host
platform system routines. In the latter case, the messages may
platform system routines. In the latter case, the messages can
vary between platforms, but should reflect similar
information. These differences in messages will result in a
<quote>failed</quote> regression test that can be validated by
......@@ -207,7 +207,7 @@ gmake installcheck
<para>
If you run the tests against an already-installed server that was
initialized with a collation-order locale other than C, then
there may be differences due to sort order and follow-up
there might be differences due to sort order and follow-up
failures. The regression test suite is set up to handle this
problem by providing alternative result files that together are
known to handle a large number of locales.
......
doc/src/sgml/release.sgml
View file @ a134ee33
This diff is collapsed.
doc/src/sgml/rowtypes.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/rowtypes.sgml,v 2.7 2007/01/30 22:29:23 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/rowtypes.sgml,v 2.8 2007/01/31 20:56:18 momjian Exp $ -->
<sect1 id="rowtypes">
<title>Composite Types</title>
......@@ -99,7 +99,7 @@ CREATE TABLE inventory_item (
<para>
To write a composite value as a literal constant, enclose the field
values within parentheses and separate them by commas. You may put double
values within parentheses and separate them by commas. You can put double
quotes around any field value, and must do so if it contains commas or
parentheses. (More details appear below.) Thus, the general format of a
composite constant is the following:
......@@ -133,7 +133,7 @@ CREATE TABLE inventory_item (
</para>
<para>
The <literal>ROW</literal> expression syntax may also be used to
The <literal>ROW</literal> expression syntax can also be used to
construct composite values. In most cases this is considerably
simpler to use than the string-literal syntax, since you don't have
to worry about multiple layers of quoting. We already used this
......@@ -252,7 +252,7 @@ INSERT INTO mytab (complex_col.r, complex_col.i) VALUES(1.1, 2.2);
The decoration consists of parentheses (<literal>(</> and <literal>)</>)
around the whole value, plus commas (<literal>,</>) between adjacent
items. Whitespace outside the parentheses is ignored, but within the
parentheses it is considered part of the field value, and may or may not be
parentheses it is considered part of the field value, and might or might not be
significant depending on the input conversion rules for the field data type.
For example, in
<programlisting>
......@@ -263,7 +263,7 @@ INSERT INTO mytab (complex_col.r, complex_col.i) VALUES(1.1, 2.2);
</para>
<para>
As shown previously, when writing a composite value you may write double
As shown previously, when writing a composite value you can write double
quotes around any individual field value.
You <emphasis>must</> do so if the field value would otherwise
confuse the composite-value parser. In particular, fields containing
......@@ -309,7 +309,7 @@ INSERT ... VALUES (E'("\\"\\\\")');
with a data type whose input routine also treated backslashes specially,
<type>bytea</> for example, we might need as many as eight backslashes
in the command to get one backslash into the stored composite field.)
Dollar quoting (see <xref linkend="sql-syntax-dollar-quoting">) may be
Dollar quoting (see <xref linkend="sql-syntax-dollar-quoting">) can be
used to avoid the need to double backslashes.
</para>
</note>
......
doc/src/sgml/rules.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/rules.sgml,v 1.48 2006/12/27 16:07:36 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/rules.sgml,v 1.49 2007/01/31 20:56:18 momjian Exp $ -->
<chapter id="rules">
<title>The Rule System</title>
......@@ -1807,7 +1807,7 @@ GRANT SELECT ON phone_number TO secretary;
the originally given query will be executed, and its command
status will be returned as usual. (But note that if there were
any conditional <literal>INSTEAD</> rules, the negation of their qualifications
will have been added to the original query. This may reduce the
will have been added to the original query. This might reduce the
number of rows it processes, and if so the reported status will
be affected.)
</para>
......
doc/src/sgml/runtime.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.374 2006/11/25 22:44:48 petere Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.375 2007/01/31 20:56:19 momjian Exp $ -->
<chapter Id="runtime">
<title>Operating System Environment</title>
......@@ -338,9 +338,9 @@ FATAL: could not create TCP/IP listen socket
This usually means just what it suggests: you tried to start
another server on the same port where one is already running.
However, if the kernel error message is not <computeroutput>Address
already in use</computeroutput> or some variant of that, there may
already in use</computeroutput> or some variant of that, there might
be a different problem. For example, trying to start a server
on a reserved port number may draw something like:
on a reserved port number might draw something like:
<screen>
$ <userinput>postgres -p 666</userinput>
LOG: could not bind IPv4 socket: Permission denied
......@@ -363,7 +363,7 @@ DETAIL: Failed system call was shmget(key=5440001, size=4011376640, 03600).
can try starting the server with a smaller-than-normal number of
buffers (<xref linkend="guc-shared-buffers">). You will eventually want
to reconfigure your kernel to increase the allowed shared memory
size. You may also see this message when trying to start multiple
size. You might also see this message when trying to start multiple
servers on the same machine, if their total space requested
exceeds the kernel limit.
</para>
......@@ -378,7 +378,7 @@ DETAIL: Failed system call was semget(5440126, 17, 03600).
space. It means your kernel's limit on the number of <systemitem
class="osname">System V</> semaphores is smaller than the number
<productname>PostgreSQL</productname> wants to create. As above,
you may be able to work around the problem by starting the
you might be able to work around the problem by starting the
server with a reduced number of allowed connections
(<xref linkend="guc-max-connections">), but you'll eventually want to
increase the kernel limit.
......@@ -442,7 +442,7 @@ psql: could not connect to server: No such file or directory
connection request and rejected it. That case will produce a
different message, as shown in <xref
linkend="client-authentication-problems">.) Other error messages
such as <computeroutput>Connection timed out</computeroutput> may
such as <computeroutput>Connection timed out</computeroutput> might
indicate more fundamental problems, like lack of network
connectivity.
</para>
......@@ -861,7 +861,7 @@ options SEMMAP=256
</para>
<para>
Older distributions may not have the <command>sysctl</command> program,
Older distributions might not have the <command>sysctl</command> program,
but equivalent changes can be made by manipulating the
<filename>/proc</filename> file system:
<screen>
......@@ -900,7 +900,7 @@ sysctl -w kern.sysv.shmall
<para>
In OS X 10.3.9 and later, instead of editing <filename>/etc/rc</>
you may create a file named <filename>/etc/sysctl.conf</>,
you can create a file named <filename>/etc/sysctl.conf</>,
containing variable assignments such as
<programlisting>
kern.sysv.shmmax=4194304
......@@ -970,11 +970,11 @@ kern.sysv.shmall=1024
sort of configuration commonly used for other databases such
as <application>DB/2</application>.</para>
<para> It may, however, be necessary to modify the global
<para> It might , however, be necessary to modify the global
<command>ulimit</command> information in
<filename>/etc/security/limits</filename>, as the default hard
limits for file sizes (<varname>fsize</varname>) and numbers of
files (<varname>nofiles</varname>) may be too low.
files (<varname>nofiles</varname>) might be too low.
</para>
</listitem>
</varlistentry>
......@@ -1158,7 +1158,7 @@ default:\
<quote>socially friendly</quote> values that allow many users to
coexist on a machine without using an inappropriate fraction of
the system resources. If you run many servers on a machine this
is perhaps what you want, but on dedicated servers you may want to
is perhaps what you want, but on dedicated servers you might want to
raise this limit.
</para>
......@@ -1179,7 +1179,7 @@ default:\
<para>
In Linux 2.4 and later, the default virtual memory behavior is not
optimal for <productname>PostgreSQL</productname>. Because of the
way that the kernel implements memory overcommit, the kernel may
way that the kernel implements memory overcommit, the kernel might
terminate the <productname>PostgreSQL</productname> server (the
master server process) if the memory demands of
another process cause the system to run out of virtual memory.
......@@ -1214,7 +1214,7 @@ Out of Memory: Killed process 12345 (postgres).
sysctl -w vm.overcommit_memory=2
</programlisting>
or placing an equivalent entry in <filename>/etc/sysctl.conf</>.
You may also wish to modify the related setting
You might also wish to modify the related setting
<literal>vm.overcommit_ratio</>. For details see the kernel documentation
file <filename>Documentation/vm/overcommit-accounting</>.
</para>
......@@ -1314,7 +1314,7 @@ $ <userinput>kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`</userinput
<para>
It is best not to use <systemitem>SIGKILL</systemitem> to shut down
the server. Doing so will prevent the server from releasing
shared memory and semaphores, which may then have to be done
shared memory and semaphores, which might then have to be done
manually before a new server can be started. Furthermore,
<systemitem>SIGKILL</systemitem> kills the <command>postgres</command>
process without letting it relay the signal to its subprocesses,
......
doc/src/sgml/sources.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/sources.sgml,v 2.20 2006/10/23 18:10:32 petere Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/sources.sgml,v 2.21 2007/01/31 20:56:19 momjian Exp $ -->
<chapter id="source">
<title>PostgreSQL Coding Conventions</title>
......@@ -95,7 +95,7 @@ ereport(ERROR,
func_signature_string(funcname, nargs,
actual_arg_types)),
errhint("Unable to choose a best candidate function. "
"You may need to add explicit typecasts.")));
"You might need to add explicit typecasts.")));
</programlisting>
This illustrates the use of format codes to embed run-time values into
a message text. Also, an optional <quote>hint</> message is provided.
......@@ -276,7 +276,7 @@ Hint: the addendum
<para>
Rationale: keeping the primary message short helps keep it to the point,
and lets clients lay out screen space on the assumption that one line is
enough for error messages. Detail and hint messages may be relegated to a
enough for error messages. Detail and hint messages can be relegated to a
verbose mode, or perhaps a pop-up error-details window. Also, details and
hints would normally be suppressed from the server log to save
space. Reference to implementation details is best avoided since users
......@@ -291,7 +291,7 @@ Hint: the addendum
<para>
Don't put any specific assumptions about formatting into the message
texts. Expect clients and the server log to wrap lines to fit their own
needs. In long messages, newline characters (\n) may be used to indicate
needs. In long messages, newline characters (\n) can be used to indicate
suggested paragraph breaks. Don't end a message with a newline. Don't
use tabs or other formatting characters. (In error context displays,
newlines are automatically added to separate levels of context such as
......@@ -376,7 +376,7 @@ Hint: the addendum
messages are not grammatically complete sentences anyway. (And if they're
long enough to be more than one sentence, they should be split into
primary and detail parts.) However, detail and hint messages are longer
and may need to include multiple sentences. For consistency, they should
and might need to include multiple sentences. For consistency, they should
follow complete-sentence style even when there's only one sentence.
</para>
......@@ -435,7 +435,7 @@ cannot open file "%s"
The first one means that the attempt to open the file failed. The
message should give a reason, such as <quote>disk full</quote> or
<quote>file doesn't exist</quote>. The past tense is appropriate because
next time the disk might not be full anymore or the file in question may
next time the disk might not be full anymore or the file in question might
exist.
</para>
......
doc/src/sgml/spi.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/spi.sgml,v 1.49 2006/10/23 18:10:32 petere Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/spi.sgml,v 1.50 2007/01/31 20:56:19 momjian Exp $ -->
<chapter id="spi">
<title>Server Programming Interface</title>
......@@ -38,7 +38,7 @@
Note that if a command invoked via SPI fails, then control will not be
returned to your procedure. Rather, the
transaction or subtransaction in which your procedure executes will be
rolled back. (This may seem surprising given that the SPI functions mostly
rolled back. (This might seem surprising given that the SPI functions mostly
have documented error-return conventions. Those conventions only apply
for errors detected within the SPI functions themselves, however.)
It is possible to recover control after an error by establishing your own
......@@ -87,7 +87,7 @@ int SPI_connect(void)
<function>SPI_connect</function> opens a connection from a
procedure invocation to the SPI manager. You must call this
function if you want to execute commands through SPI. Some utility
SPI functions may be called from unconnected procedures.
SPI functions can be called from unconnected procedures.
</para>
<para>
......@@ -305,7 +305,7 @@ int SPI_execute(const char * <parameter>command</parameter>, bool <parameter>rea
</para>
<para>
This function may only be called from a connected procedure.
This function can only be called from a connected procedure.
</para>
<para>
......@@ -321,7 +321,7 @@ SPI_execute("INSERT INTO foo SELECT * FROM bar", false, 5);
</para>
<para>
You may pass multiple commands in one string.
You can pass multiple commands in one string.
<function>SPI_execute</function> returns the
result for the command executed last. The <parameter>count</parameter>
limit applies to each command separately, but it is not applied to
......@@ -366,7 +366,7 @@ SPI_execute("INSERT INTO foo SELECT * FROM bar", false, 5);
<symbol>SPI_OK_INSERT_RETURNING</symbol>,
<symbol>SPI_OK_DELETE_RETURNING</symbol>, or
<symbol>SPI_OK_UPDATE_RETURNING</symbol>,
then you may use the
then you can use the
global pointer <literal>SPITupleTable *SPI_tuptable</literal> to
access the result rows. Some utility commands (such as
<command>EXPLAIN</>) also return row sets, and <literal>SPI_tuptable</>
......@@ -388,7 +388,7 @@ typedef struct
</programlisting>
<structfield>vals</> is an array of pointers to rows. (The number
of valid entries is given by <varname>SPI_processed</varname>.)
<structfield>tupdesc</> is a row descriptor which you may pass to
<structfield>tupdesc</> is a row descriptor which you can pass to
SPI functions dealing with rows. <structfield>tuptabcxt</>,
<structfield>alloced</>, and <structfield>free</> are internal
fields not intended for use by SPI callers.
......@@ -713,7 +713,7 @@ void * SPI_prepare(const char * <parameter>command</parameter>, int <parameter>n
<para>
When the same or a similar command is to be executed repeatedly, it
may be advantageous to perform the planning only once.
might be advantageous to perform the planning only once.
<function>SPI_prepare</function> converts a command string into an
execution plan that can be executed repeatedly using
<function>SPI_execute_plan</function>.
......@@ -792,7 +792,7 @@ void * SPI_prepare(const char * <parameter>command</parameter>, int <parameter>n
<para>
There is a disadvantage to using parameters: since the planner does
not know the values that will be supplied for the parameters, it
may make worse planning choices than it would make for a normal
might make worse planning choices than it would make for a normal
command with all constants visible.
</para>
</refsect1>
......@@ -1685,7 +1685,7 @@ void * SPI_saveplan(void * <parameter>plan</parameter>)
</para>
<para>
All functions described in this section may be used by both
All functions described in this section can be used by both
connected and unconnected procedures.
</para>
......@@ -2311,7 +2311,7 @@ char * SPI_getnspname(Relation <parameter>rel</parameter>)
</para>
<para>
All functions described in this section may be used by both
All functions described in this section can be used by both
connected and unconnected procedures. In an unconnected procedure,
they act the same as the underlying ordinary server functions
(<function>palloc</>, etc.).
......
doc/src/sgml/sql.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/sql.sgml,v 1.43 2007/01/09 02:14:10 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/sql.sgml,v 1.44 2007/01/31 20:56:19 momjian Exp $ -->
<chapter id="sql-intro">
<title>SQL</title>
......@@ -173,9 +173,9 @@ PART: 4 | 3
</para>
<para>
The tables PART and SUPPLIER may be regarded as
The tables PART and SUPPLIER can be regarded as
<firstterm>entities</firstterm> and
SELLS may be regarded as a <firstterm>relationship</firstterm>
SELLS can be regarded as a <firstterm>relationship</firstterm>
between a particular
part and a particular supplier.
</para>
......@@ -949,7 +949,7 @@ SELECT PNAME, PRICE
</para>
<para>
Arithmetic operations may be used in the target list and in the WHERE
Arithmetic operations can be used in the target list and in the WHERE
clause. For example if we want to know how much it would cost if we
take two pieces of a part we could use the following query:
......@@ -1059,7 +1059,7 @@ select sname, pname from supplier
A joined table, created using JOIN syntax, is a table reference list
item that occurs in a FROM clause and before any WHERE, GROUP BY,
or HAVING clause. Other table references, including table names or
other JOIN clauses, may be included in the FROM clause if separated
other JOIN clauses, can be included in the FROM clause if separated
by commas. JOINed tables are logically like any other
table listed in the FROM clause.
</para>
......@@ -1239,7 +1239,7 @@ select sname, pname from supplier
<para>
JOINs of all types can be chained together or nested where either or both of
<replaceable class="parameter">T1</replaceable> and
<replaceable class="parameter">T2</replaceable> may be JOINed tables.
<replaceable class="parameter">T2</replaceable> can be JOINed tables.
Parenthesis can be used around JOIN clauses to control the order
of JOINs which are otherwise processed left to right.
</para>
......@@ -1405,7 +1405,7 @@ SELECT S.SNO, S.SNAME, COUNT(SE.PNO)
<para>
Note that for a query using GROUP BY and aggregate
functions to make sense, the target list can only refer directly to
the attributes being grouped by. Other attributes may only be used
the attributes being grouped by. Other attributes can only be used
inside the arguments of aggregate functions. Otherwise there would
not be a unique value to associate with the other attributes.
</para>
......@@ -1825,7 +1825,7 @@ CREATE INDEX I ON SUPPLIER (SNAME);
<title>Create View</title>
<para>
A view may be regarded as a <firstterm>virtual table</firstterm>,
A view can be regarded as a <firstterm>virtual table</firstterm>,
i.e. a table that
does not <emphasis>physically</emphasis> exist in the database
but looks to the user
......
doc/src/sgml/start.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/start.sgml,v 1.43 2006/10/21 23:12:57 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/start.sgml,v 1.44 2007/01/31 20:56:19 momjian Exp $ -->
<chapter id="tutorial-start">
<title>Getting Started</title>
......@@ -38,11 +38,11 @@
<para>
If your site administrator has not set things up in the default
way, you may have some more work to do. For example, if the
way, you might have some more work to do. For example, if the
database server machine is a remote machine, you will need to set
the <envar>PGHOST</envar> environment variable to the name of the
database server machine. The environment variable
<envar>PGPORT</envar> may also have to be set. The bottom line is
<envar>PGPORT</envar> might also have to be set. The bottom line is
this: if you try to start an application program and it complains
that it cannot connect to the database, you should consult your
site administrator or, if that is you, the documentation to make
......@@ -272,7 +272,7 @@ createdb: database creation failed: ERROR: permission denied to create database
</para>
<para>
More about <command>createdb</command> and <command>dropdb</command> may
More about <command>createdb</command> and <command>dropdb</command> can
be found in <xref linkend="APP-CREATEDB"> and <xref linkend="APP-DROPDB">
respectively.
</para>
......
doc/src/sgml/storage.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/storage.sgml,v 1.13 2006/11/25 22:55:59 petere Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/storage.sgml,v 1.14 2007/01/31 20:56:19 momjian Exp $ -->
<chapter id="storage">
......@@ -365,7 +365,7 @@ fixed size (usually 8 kB, although a different page size can be selected
when compiling the server). In a table, all the pages are logically
equivalent, so a particular item (row) can be stored in any page. In
indexes, the first page is generally reserved as a <firstterm>metapage</>
holding control information, and there may be different types of pages
holding control information, and there can be different types of pages
within the index, depending on the index access method.
</para>
......@@ -503,7 +503,7 @@ data. Empty in ordinary tables.</entry>
</table>
<para>
All the details may be found in
All the details can be found in
<filename>src/include/storage/bufpage.h</filename>.
</para>
......@@ -519,7 +519,7 @@ data. Empty in ordinary tables.</entry>
The number of item identifiers present can be determined by looking at
<structfield>pd_lower</>, which is increased to allocate a new identifier.
Because an item
identifier is never moved until it is freed, its index may be used on a
identifier is never moved until it is freed, its index can be used on a
long-term basis to reference an item, even when the item itself is moved
around on the page to compact free space. In fact, every pointer to an
item (<type>ItemPointer</type>, also known as
......@@ -540,8 +540,8 @@ data. Empty in ordinary tables.</entry>
<para>
The final section is the <quote>special section</quote> which may
contain anything the access method wishes to store. For example,
The final section is the <quote>special section</quote> which can
contain anything the access method wishes to store. For example,
b-tree indexes store links to the page's left and right siblings,
as well as some other data relevant to the index structure.
Ordinary tables do not use a special section at all (indicated by setting
......@@ -647,7 +647,7 @@ data. Empty in ordinary tables.</entry>
</table>
<para>
All the details may be found in
All the details can be found in
<filename>src/include/access/htup.h</filename>.
</para>
......@@ -673,7 +673,7 @@ data. Empty in ordinary tables.</entry>
variable length field (attlen = -1) then it's a bit more complicated.
All variable-length datatypes share the common header structure
<type>varattrib</type>, which includes the total length of the stored
value and some flag bits. Depending on the flags, the data may be either
value and some flag bits. Depending on the flags, the data can be either
inline or in a <acronym>TOAST</> table;
it might be compressed, too (see <xref linkend="storage-toast">).
......
doc/src/sgml/syntax.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/syntax.sgml,v 1.111 2006/10/22 03:03:41 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/syntax.sgml,v 1.112 2007/01/31 20:56:19 momjian Exp $ -->
<chapter id="sql-syntax">
<title>SQL Syntax</title>
......@@ -120,7 +120,7 @@ INSERT INTO MY_TABLE VALUES (3, 'hi there');
key word can be letters, underscores, digits
(<literal>0</literal>-<literal>9</literal>), or dollar signs
(<literal>$</>). Note that dollar signs are not allowed in identifiers
according to the letter of the SQL standard, so their use may render
according to the letter of the SQL standard, so their use might render
applications less portable.
The SQL standard will not define a key word that contains
digits or starts or ends with an underscore, so identifiers of this
......@@ -466,7 +466,7 @@ $function$
digits (0 through 9). At least one digit must be before or after the
decimal point, if one is used. At least one digit must follow the
exponent marker (<literal>e</literal>), if one is present.
There may not be any spaces or other characters embedded in the
There cannot be any spaces or other characters embedded in the
constant. Note that any leading plus or minus sign is not actually
considered part of the constant; it is an operator applied to the
constant.
......@@ -537,7 +537,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
The string constant's text is passed to the input conversion
routine for the type called <replaceable>type</replaceable>. The
result is a constant of the indicated type. The explicit type
cast may be omitted if there is no ambiguity as to the type the
cast can be omitted if there is no ambiguity as to the type the
constant must be (for example, when it is assigned directly to a
table column), in which case it is automatically coerced.
</para>
......@@ -553,7 +553,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
<synopsis>
<replaceable>typename</replaceable> ( '<replaceable>string</replaceable>' )
</synopsis>
but not all type names may be used in this way; see <xref
but not all type names can be used in this way; see <xref
linkend="sql-syntax-type-casts"> for details.
</para>
......@@ -650,7 +650,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
A dollar sign (<literal>$</literal>) followed by digits is used
to represent a positional parameter in the body of a function
definition or a prepared statement. In other contexts the
dollar sign may be part of an identifier or a dollar-quoted string
dollar sign can be part of an identifier or a dollar-quoted string
constant.
</para>
</listitem>
......@@ -743,7 +743,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
where the comment begins with <literal>/*</literal> and extends to
the matching occurrence of <literal>*/</literal>. These block
comments nest, as specified in the SQL standard but unlike C, so that one can
comment out larger blocks of code that may contain existing block
comment out larger blocks of code that might contain existing block
comments.
</para>
......@@ -766,7 +766,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
associativity of the operators in <productname>PostgreSQL</>.
Most operators have the same precedence and are left-associative.
The precedence and associativity of the operators is hard-wired
into the parser. This may lead to non-intuitive behavior; for
into the parser. This can lead to non-intuitive behavior; for
example the Boolean operators <literal>&lt;</> and
<literal>&gt;</> have a different precedence than the Boolean
operators <literal>&lt;=</> and <literal>&gt;=</>. Also, you will
......@@ -1101,7 +1101,7 @@ SELECT 3 OPERATOR(pg_catalog.+) 4;
the key words <literal>NEW</literal> or <literal>OLD</literal>.
(<literal>NEW</literal> and <literal>OLD</literal> can only appear in rewrite rules,
while other correlation names can be used in any SQL statement.)
The correlation name and separating dot may be omitted if the column name
The correlation name and separating dot can be omitted if the column name
is unique across all the tables being used in the current query. (See also <xref linkend="queries">.)
</para>
</sect2>
......@@ -1171,7 +1171,7 @@ CREATE FUNCTION dept(text) RETURNS dept
<para>
In general the array <replaceable>expression</replaceable> must be
parenthesized, but the parentheses may be omitted when the expression
parenthesized, but the parentheses can be omitted when the expression
to be subscripted is just a column reference or positional parameter.
Also, multiple subscripts can be concatenated when the original array
is multidimensional.
......@@ -1206,7 +1206,7 @@ $1[10:42]
<para>
In general the row <replaceable>expression</replaceable> must be
parenthesized, but the parentheses may be omitted when the expression
parenthesized, but the parentheses can be omitted when the expression
to be selected from is just a table reference or positional parameter.
For example,
......@@ -1277,7 +1277,7 @@ sqrt(2)
<para>
The list of built-in functions is in <xref linkend="functions">.
Other functions may be added by the user.
Other functions can be added by the user.
</para>
</sect2>
......@@ -1334,12 +1334,12 @@ sqrt(2)
<para>
The predefined aggregate functions are described in <xref
linkend="functions-aggregate">. Other aggregate functions may be added
linkend="functions-aggregate">. Other aggregate functions can be added
by the user.
</para>
<para>
An aggregate expression may only appear in the result list or
An aggregate expression can only appear in the result list or
<literal>HAVING</> clause of a <command>SELECT</> command.
It is forbidden in other clauses, such as <literal>WHERE</>,
because those clauses are logically evaluated before the results
......@@ -1407,7 +1407,7 @@ CAST ( <replaceable>expression</replaceable> AS <replaceable>type</replaceable>
</para>
<para>
An explicit type cast may usually be omitted if there is no ambiguity as
An explicit type cast can usually be omitted if there is no ambiguity as
to the type that a value expression must produce (for example, when it is
assigned to a table column); the system will automatically apply a
type cast in such cases. However, automatic casting is only done for
......@@ -1510,7 +1510,7 @@ SELECT ARRAY[1,2,3+4];
<para>
Multidimensional array values can be built by nesting array
constructors.
In the inner constructors, the key word <literal>ARRAY</literal> may
In the inner constructors, the key word <literal>ARRAY</literal> can
be omitted. For example, these produce the same result:
<programlisting>
......@@ -1634,7 +1634,7 @@ SELECT ROW(t.f1, t.f2, 42) FROM t;
By default, the value created by a <literal>ROW</> expression is of
an anonymous record type. If necessary, it can be cast to a named
composite type &mdash; either the row type of a table, or a composite type
created with <command>CREATE TYPE AS</>. An explicit cast may be needed
created with <command>CREATE TYPE AS</>. An explicit cast might be needed
to avoid ambiguity. For example:
<programlisting>
CREATE TABLE mytable(f1 int, f2 float, f3 text);
......@@ -1725,13 +1725,13 @@ SELECT somefunc() OR true;
rely on side effects or evaluation order in <literal>WHERE</> and <literal>HAVING</> clauses,
since those clauses are extensively reprocessed as part of
developing an execution plan. Boolean
expressions (<literal>AND</>/<literal>OR</>/<literal>NOT</> combinations) in those clauses may be reorganized
expressions (<literal>AND</>/<literal>OR</>/<literal>NOT</> combinations) in those clauses can be reorganized
in any manner allowed by the laws of Boolean algebra.
</para>
<para>
When it is essential to force evaluation order, a <literal>CASE</>
construct (see <xref linkend="functions-conditional">) may be
construct (see <xref linkend="functions-conditional">) can be
used. For example, this is an untrustworthy way of trying to
avoid division by zero in a <literal>WHERE</> clause:
<programlisting>
......
doc/src/sgml/trigger.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/trigger.sgml,v 1.47 2006/09/16 00:30:16 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/trigger.sgml,v 1.48 2007/01/31 20:56:19 momjian Exp $ -->
<chapter id="triggers">
<title>Triggers</title>
......@@ -122,7 +122,7 @@
<para>
The return value is ignored for row-level triggers fired after an
operation, and so they may as well return <symbol>NULL</>.
operation, and so they can return <symbol>NULL</>.
</para>
<para>
......@@ -152,7 +152,7 @@
<para>
If a trigger function executes SQL commands then these
commands may fire triggers again. This is known as cascading
commands might fire triggers again. This is known as cascading
triggers. There is no direct limitation on the number of cascade
levels. It is possible for cascades to cause a recursive invocation
of the same trigger; for example, an <command>INSERT</command>
......@@ -233,7 +233,7 @@
changes for rows previously processed in the same outer
command. This requires caution, since the ordering of these
change events is not in general predictable; a SQL command that
affects multiple rows may visit the rows in any order.
affects multiple rows can visit the rows in any order.
</para>
</listitem>
......@@ -332,7 +332,7 @@ typedef struct TriggerData
<term><structfield>tg_event</></term>
<listitem>
<para>
Describes the event for which the function is called. You may use the
Describes the event for which the function is called. You can use the
following macros to examine <literal>tg_event</literal>:
<variablelist>
......@@ -524,7 +524,7 @@ typedef struct Trigger
<para>
Here is a very simple example of a trigger function written in C.
(Examples of triggers written in procedural languages may be found
(Examples of triggers written in procedural languages can be found
in the documentation of the procedural languages.)
</para>
......
doc/src/sgml/typeconv.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/typeconv.sgml,v 1.48 2006/09/18 19:54:01 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/typeconv.sgml,v 1.49 2007/01/31 20:56:19 momjian Exp $ -->
<chapter Id="typeconv">
<title>Type Conversion</title>
......@@ -447,7 +447,7 @@ try a similar case with <literal>~</>, we get:
SELECT ~ '20' AS "negation";
ERROR: operator is not unique: ~ "unknown"
HINT: Could not choose a best candidate operator. You may need to add explicit
HINT: Could not choose a best candidate operator. You might need to add explicit
type casts.
</screen>
This happens because the system can't decide which of the several
......@@ -619,7 +619,7 @@ SELECT round(CAST (4 AS numeric), 4);
<para>
Since numeric constants with decimal points are initially assigned the
type <type>numeric</type>, the following query will require no type
conversion and may therefore be slightly more efficient:
conversion and might therefore be slightly more efficient:
<screen>
SELECT round(4.0, 4);
</screen>
......
doc/src/sgml/user-manag.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/user-manag.sgml,v 1.37 2006/09/05 21:08:34 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/user-manag.sgml,v 1.38 2007/01/31 20:56:19 momjian Exp $ -->
<chapter id="user-manag">
<title>Database Roles and Privileges</title>
......@@ -126,7 +126,7 @@ SELECT rolname FROM pg_roles;
</para>
<para>
The set of database roles a given client connection may connect as
The set of database roles a given client connection can connect as
is determined by the client authentication setup, as explained in
<xref linkend="client-authentication">. (Thus, a client is not
necessarily limited to connect as the role with the same name as
......@@ -142,7 +142,7 @@ SELECT rolname FROM pg_roles;
<title>Role Attributes</title>
<para>
A database role may have a number of attributes that define its
A database role can have a number of attributes that define its
privileges and interact with the client authentication system.
<variablelist>
......@@ -482,7 +482,7 @@ DROP ROLE <replaceable>name</replaceable>;
<para>
Functions and triggers allow users to insert code into the backend
server that other users may execute unintentionally. Hence, both
server that other users might execute unintentionally. Hence, both
mechanisms permit users to <quote>Trojan horse</quote>
others with relative ease. The only real protection is tight
control over who can define functions.
......
doc/src/sgml/wal.sgml
View file @ a134ee33
This diff is collapsed.
doc/src/sgml/xaggr.sgml
View file @ a134ee33
<!-- $PostgreSQL: pgsql/doc/src/sgml/xaggr.sgml,v 1.33 2006/09/16 00:30:16 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/xaggr.sgml,v 1.34 2007/01/31 20:56:20 momjian Exp $ -->
<sect1 id="xaggr">
<title>User-Defined Aggregates</title>
......@@ -28,7 +28,7 @@
<para>
Thus, in addition to the argument and result data types seen by a user
of the aggregate, there is an internal state-value data type that
may be different from both the argument and result types.
might be different from both the argument and result types.
</para>
<para>
......@@ -112,12 +112,12 @@ CREATE AGGREGATE avg (float8)
</para>
<para>
Aggregate functions may use polymorphic
Aggregate functions can use polymorphic
state transition functions or final functions, so that the same functions
can be used to implement multiple aggregates.
See <xref linkend="extend-types-polymorphic">
for an explanation of polymorphic functions.
Going a step further, the aggregate function itself may be specified
Going a step further, the aggregate function itself can be specified
with polymorphic input type(s) and state type, allowing a single
aggregate definition to serve for multiple input data types.
Here is an example of a polymorphic aggregate:
......
doc/src/sgml/xfunc.sgml
View file @ a134ee33
This diff is collapsed.
doc/src/sgml/xindex.sgml
View file @ a134ee33
This diff is collapsed.
doc/src/sgml/xoper.sgml
View file @ a134ee33
This diff is collapsed.
doc/src/sgml/xplang.sgml
View file @ a134ee33
This diff is collapsed.
src/backend/parser/parse_func.c
View file @ a134ee33
This diff is collapsed.
src/backend/parser/parse_oper.c
View file @ a134ee33
This diff is collapsed.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment