mirror of
https://github.com/postgres/postgres.git
synced 2025-05-02 11:44:50 +03:00
doc: add commas after 'i.e.' and 'e.g.'
This follows the American format, https://jakubmarian.com/comma-after-i-e-and-e-g/. There is no intention of requiring this format for future text, but making existing text consistent every few years makes sense. Discussion: https://postgr.es/m/20200825183619.GA22369@momjian.us Backpatch-through: 9.5
This commit is contained in:
parent
7d26d85f1b
commit
ffc61f865b
@ -407,7 +407,7 @@ include_dir 'directory'
|
||||
start with the <literal>.</literal> character are also ignored, to
|
||||
prevent mistakes since such files are hidden on some platforms. Multiple
|
||||
files within an include directory are processed in file name order
|
||||
(according to C locale rules, i.e. numbers before letters, and
|
||||
(according to C locale rules, i.e., numbers before letters, and
|
||||
uppercase letters before lowercase ones).
|
||||
</para>
|
||||
|
||||
@ -1304,7 +1304,7 @@ include_dir 'conf.d'
|
||||
<para>
|
||||
With this parameter enabled, you can still create ordinary global
|
||||
users. Simply append <literal>@</> when specifying the user
|
||||
name in the client, e.g. <literal>joe@</>. The <literal>@</>
|
||||
name in the client, e.g., <literal>joe@</>. The <literal>@</>
|
||||
will be stripped off before the user name is looked up by the
|
||||
server.
|
||||
</para>
|
||||
@ -2886,7 +2886,7 @@ include_dir 'conf.d'
|
||||
disabled, but the server continues to accumulate WAL segment files in
|
||||
the expectation that a command will soon be provided. Setting
|
||||
<varname>archive_command</> to a command that does nothing but
|
||||
return true, e.g. <literal>/bin/true</> (<literal>REM</> on
|
||||
return true, e.g., <literal>/bin/true</> (<literal>REM</> on
|
||||
Windows), effectively disables
|
||||
archiving, but also breaks the chain of WAL files needed for
|
||||
archive recovery, so it should only be used in unusual circumstances.
|
||||
@ -3836,7 +3836,7 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
|
||||
if your data is likely to be completely in cache, such as when
|
||||
the database is smaller than the total server memory, decreasing
|
||||
random_page_cost can be appropriate. Storage that has a low random
|
||||
read cost relative to sequential, e.g. solid-state drives, might
|
||||
read cost relative to sequential, e.g., solid-state drives, might
|
||||
also be better modeled with a lower value for random_page_cost,
|
||||
e.g., <literal>1.1</literal>.
|
||||
</para>
|
||||
@ -7384,7 +7384,7 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
|
||||
rows that can be locked; that value is unlimited. The default,
|
||||
64, has historically proven sufficient, but you might need to
|
||||
raise this value if you have queries that touch many different
|
||||
tables in a single transaction, e.g. query of a parent table with
|
||||
tables in a single transaction, e.g., query of a parent table with
|
||||
many children. This parameter can only be set at server start.
|
||||
</para>
|
||||
|
||||
@ -7895,7 +7895,7 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
|
||||
with assertions enabled. That is the case if the
|
||||
macro <symbol>USE_ASSERT_CHECKING</symbol> is defined
|
||||
when <productname>PostgreSQL</productname> is built (accomplished
|
||||
e.g. by the <command>configure</command> option
|
||||
e.g., by the <command>configure</command> option
|
||||
<option>--enable-cassert</option>). By
|
||||
default <productname>PostgreSQL</productname> is built without
|
||||
assertions.
|
||||
|
@ -507,7 +507,7 @@
|
||||
very large number of digits. It is especially recommended for
|
||||
storing monetary amounts and other quantities where exactness is
|
||||
required. Calculations with <type>numeric</type> values yield exact
|
||||
results where possible, e.g. addition, subtraction, multiplication.
|
||||
results where possible, e.g., addition, subtraction, multiplication.
|
||||
However, calculations on <type>numeric</type> values are very slow
|
||||
compared to the integer types, or to the floating-point types
|
||||
described in the next section.
|
||||
@ -4870,7 +4870,7 @@ SELECT * FROM pg_attribute
|
||||
|
||||
<row>
|
||||
<entry><type>unknown</></entry>
|
||||
<entry>Identifies a not-yet-resolved type, e.g. of an undecorated
|
||||
<entry>Identifies a not-yet-resolved type, e.g., of an undecorated
|
||||
string literal.</entry>
|
||||
</row>
|
||||
|
||||
|
@ -1511,7 +1511,7 @@ ALTER TABLE products RENAME TO items;
|
||||
|
||||
<para>
|
||||
An object can be assigned to a new owner with an <command>ALTER</command>
|
||||
command of the appropriate kind for the object, e.g. <xref
|
||||
command of the appropriate kind for the object, e.g., <xref
|
||||
linkend="sql-altertable">. Superusers can always do
|
||||
this; ordinary roles can only do it if they are both the current owner
|
||||
of the object (or a member of the owning role) and a member of the new
|
||||
|
@ -3659,7 +3659,7 @@ EXEC SQL DEALLOCATE DESCRIPTOR <replaceable>identifier</replaceable>;
|
||||
EXEC SQL FETCH NEXT FROM mycursor INTO SQL DESCRIPTOR mydesc;
|
||||
</programlisting>
|
||||
If the result set is empty, the Descriptor Area will still contain
|
||||
the metadata from the query, i.e. the field names.
|
||||
the metadata from the query, i.e., the field names.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -4076,7 +4076,7 @@ typedef struct sqlvar_struct sqlvar_t;
|
||||
<term><literal>sqllen</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Contains the binary length of the field. e.g. 4 bytes for <type>ECPGt_int</type>.
|
||||
Contains the binary length of the field. e.g., 4 bytes for <type>ECPGt_int</type>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -8003,7 +8003,7 @@ EXEC SQL CLOSE DATABASE;
|
||||
<term><literal>FREE cursor_name</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Due to the differences how ECPG works compared to Informix's ESQL/C (i.e. which steps
|
||||
Due to the differences how ECPG works compared to Informix's ESQL/C (i.e., which steps
|
||||
are purely grammar transformations and which steps rely on the underlying run-time library)
|
||||
there is no <literal>FREE cursor_name</> statement in ECPG. This is because in ECPG,
|
||||
<literal>DECLARE CURSOR</literal> doesn't translate to a function call into
|
||||
|
@ -542,7 +542,7 @@
|
||||
<para>
|
||||
An extension is <firstterm>relocatable</> if it is possible to move
|
||||
its contained objects into a different schema after initial creation
|
||||
of the extension. The default is <literal>false</>, i.e. the
|
||||
of the extension. The default is <literal>false</>, i.e., the
|
||||
extension is not relocatable.
|
||||
See <xref linkend="extend-extensions-relocation"> for more information.
|
||||
</para>
|
||||
@ -1363,7 +1363,7 @@ include $(PGXS)
|
||||
<term><varname>NO_INSTALLCHECK</varname></term>
|
||||
<listitem>
|
||||
<para>
|
||||
don't define an <literal>installcheck</literal> target, useful e.g. if tests require special configuration, or don't use <application>pg_regress</application>
|
||||
don't define an <literal>installcheck</literal> target, useful e.g., if tests require special configuration, or don't use <application>pg_regress</application>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -6211,7 +6211,7 @@ SELECT regexp_match('abc01234xyz', '(?:(.*?)(\d+)(.*)){1,1}');
|
||||
will be replaced by the year data, but the single <literal>Y</literal> in <literal>Year</literal>
|
||||
will not be. In <function>to_date</>, <function>to_number</>,
|
||||
and <function>to_timestamp</>, double-quoted strings skip the number of
|
||||
input characters contained in the string, e.g. <literal>"XX"</>
|
||||
input characters contained in the string, e.g., <literal>"XX"</>
|
||||
skips two input characters.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -6227,9 +6227,9 @@ SELECT regexp_match('abc01234xyz', '(?:(.*?)(\d+)(.*)){1,1}');
|
||||
<listitem>
|
||||
<para>
|
||||
In <function>to_timestamp</function> and <function>to_date</function>,
|
||||
if the year format specification is less than four digits, e.g.
|
||||
if the year format specification is less than four digits, e.g.,
|
||||
<literal>YYY</>, and the supplied year is less than four digits,
|
||||
the year will be adjusted to be nearest to the year 2020, e.g.
|
||||
the year will be adjusted to be nearest to the year 2020, e.g.,
|
||||
<literal>95</> becomes 1995.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -20607,7 +20607,7 @@ FOR EACH ROW EXECUTE PROCEDURE suppress_redundant_updates_trigger();
|
||||
<row>
|
||||
<entry><literal>objsubid</literal></entry>
|
||||
<entry><type>integer</type></entry>
|
||||
<entry>Sub-object ID (e.g. attribute number for a column)</entry>
|
||||
<entry>Sub-object ID (e.g., attribute number for a column)</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>command_tag</literal></entry>
|
||||
@ -20694,7 +20694,7 @@ FOR EACH ROW EXECUTE PROCEDURE suppress_redundant_updates_trigger();
|
||||
<row>
|
||||
<entry><literal>objsubid</literal></entry>
|
||||
<entry><type>integer</type></entry>
|
||||
<entry>Sub-object ID (e.g. attribute number for a column)</entry>
|
||||
<entry>Sub-object ID (e.g., attribute number for a column)</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>original</literal></entry>
|
||||
|
@ -219,7 +219,7 @@ protocol to make nodes agree on a serializable transactional order.
|
||||
this is unacceptable, either the middleware or the application
|
||||
must query such values from a single server and then use those
|
||||
values in write queries. Another option is to use this replication
|
||||
option with a traditional master-standby setup, i.e. data modification
|
||||
option with a traditional master-standby setup, i.e., data modification
|
||||
queries are sent only to the master and are propagated to the
|
||||
standby servers via master-standby replication, not by the replication
|
||||
middleware. Care must also be taken that all
|
||||
@ -657,7 +657,7 @@ protocol to make nodes agree on a serializable transactional order.
|
||||
Set up continuous archiving on the primary to an archive directory
|
||||
accessible from the standby, as described
|
||||
in <xref linkend="continuous-archiving">. The archive location should be
|
||||
accessible from the standby even when the master is down, i.e. it should
|
||||
accessible from the standby even when the master is down, i.e., it should
|
||||
reside on the standby server itself or another trusted server, not on
|
||||
the master server.
|
||||
</para>
|
||||
@ -2213,7 +2213,7 @@ LOG: database system is ready to accept read only connections
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Data Definition Language (DDL) - e.g. <command>CREATE INDEX</>
|
||||
Data Definition Language (DDL) - e.g., <command>CREATE INDEX</>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -2279,7 +2279,7 @@ LOG: database system is ready to accept read only connections
|
||||
|
||||
<para>
|
||||
WAL file control commands will not work during recovery,
|
||||
e.g. <function>pg_start_backup</>, <function>pg_switch_wal</> etc.
|
||||
e.g., <function>pg_start_backup</>, <function>pg_switch_wal</> etc.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -368,7 +368,7 @@ amcanreturn (Relation indexRelation, int attno);
|
||||
linkend="indexes-index-only-scans"><firstterm>index-only scans</></link> on
|
||||
the given column, by returning the indexed column values for an index entry
|
||||
in the form of an <structname>IndexTuple</structname>. The attribute number
|
||||
is 1-based, i.e. the first column's attno is 1. Returns TRUE if supported,
|
||||
is 1-based, i.e., the first column's attno is 1. Returns TRUE if supported,
|
||||
else FALSE. If the access method does not support index-only scans at all,
|
||||
the <structfield>amcanreturn</> field in its <structname>IndexAmRoutine</>
|
||||
struct can be set to NULL.
|
||||
|
@ -108,7 +108,7 @@
|
||||
In the <productname>Microsoft Windows SDK</productname>, start the
|
||||
<application>CMD shell</application> listed under the SDK on the Start Menu.
|
||||
In recent SDK versions you can change the targeted CPU architecture, build
|
||||
type, and target OS by using the <command>setenv</command> command, e.g.
|
||||
type, and target OS by using the <command>setenv</command> command, e.g.,
|
||||
<command>setenv /x86 /release /xp</command> to target Windows XP or later
|
||||
with a 32-bit release build. See <command>/?</command> for other options to
|
||||
<command>setenv</command>. All commands should be run from the
|
||||
@ -241,7 +241,7 @@ $ENV{MSBFLAGS}="/m";
|
||||
installations <filename>C:\Program Files\GnuWin32</filename>.
|
||||
Consider installing into <filename>C:\GnuWin32</filename> or use the
|
||||
NTFS short name path to GnuWin32 in your PATH environment setting
|
||||
(e.g. <filename>C:\PROGRA~1\GnuWin32</filename>).
|
||||
(e.g., <filename>C:\PROGRA~1\GnuWin32</filename>).
|
||||
</para>
|
||||
</note>
|
||||
|
||||
|
@ -355,7 +355,7 @@ PostgresPollingStatusType PQconnectPoll(PGconn *conn);
|
||||
Conversely, if <function>PQconnectPoll(conn)</function> last returned
|
||||
<symbol>PGRES_POLLING_WRITING</symbol>, wait until the socket is ready
|
||||
to write, then call <function>PQconnectPoll(conn)</function> again.
|
||||
On the first iteration, i.e. if you have yet to call
|
||||
On the first iteration, i.e., if you have yet to call
|
||||
<function>PQconnectPoll</function>, behave as if it last returned
|
||||
<symbol>PGRES_POLLING_WRITING</symbol>. Continue this loop until
|
||||
<function>PQconnectPoll(conn)</function> returns
|
||||
@ -860,7 +860,7 @@ postgresql:///mydb?host=localhost&port=5433
|
||||
|
||||
<para>
|
||||
Percent-encoding may be used to include symbols with special meaning in any
|
||||
of the <acronym>URI</acronym> parts, e.g. replace <literal>=</> with
|
||||
of the <acronym>URI</acronym> parts, e.g., replace <literal>=</> with
|
||||
<literal>%3D</>.
|
||||
|
||||
</para>
|
||||
@ -919,7 +919,7 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
|
||||
<literal>hostaddr</>, and <literal>port</> options accept a comma-separated
|
||||
list of values. The same number of elements must be given in each
|
||||
option that is specified, such
|
||||
that e.g. the first <literal>hostaddr</> corresponds to the first host name,
|
||||
that e.g., the first <literal>hostaddr</> corresponds to the first host name,
|
||||
the second <literal>hostaddr</> corresponds to the second host name, and so
|
||||
forth. As an exception, if only one <literal>port</literal> is specified, it
|
||||
applies to all the hosts.
|
||||
@ -947,7 +947,7 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
|
||||
<para>
|
||||
If a password file is used, you can have different passwords for
|
||||
different hosts. All the other connection options are the same for every
|
||||
host in the list; it is not possible to e.g. specify different
|
||||
host in the list; it is not possible to e.g., specify different
|
||||
usernames for different hosts.
|
||||
</para>
|
||||
</sect3>
|
||||
@ -1123,7 +1123,7 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
|
||||
<listitem>
|
||||
<para>
|
||||
Maximum wait for connection, in seconds (write as a decimal integer,
|
||||
e.g. <literal>10</literal>). Zero, negative, or not specified means
|
||||
e.g., <literal>10</literal>). Zero, negative, or not specified means
|
||||
wait indefinitely. The minimum allowed timeout is 2 seconds, therefore
|
||||
a value of <literal>1</literal> is interpreted as <literal>2</literal>.
|
||||
This timeout applies separately to each host name or IP address.
|
||||
@ -2164,7 +2164,7 @@ const char *PQsslAttribute(const PGconn *conn, const char *attribute_name);
|
||||
<term><literal>cipher</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
A short name of the ciphersuite used, e.g.
|
||||
A short name of the ciphersuite used, e.g.,
|
||||
<literal>"DHE-RSA-DES-CBC3-SHA"</literal>. The names are specific
|
||||
to each SSL implementation.
|
||||
</para>
|
||||
@ -4811,7 +4811,7 @@ int PQflush(PGconn *conn);
|
||||
<function>PQflush</function> again. Repeat until
|
||||
<function>PQflush</function> returns 0. (It is necessary to check for
|
||||
read-ready and drain the input with <function>PQconsumeInput</function>,
|
||||
because the server can block trying to send us data, e.g. NOTICE
|
||||
because the server can block trying to send us data, e.g., NOTICE
|
||||
messages, and won't read our data until we read its.) Once
|
||||
<function>PQflush</function> returns 0, wait for the socket to be
|
||||
read-ready and then read the response as described above.
|
||||
@ -7820,7 +7820,7 @@ ldap://ldap.acme.com/cn=dbserver,cn=hosts?pgconnectinfo?base?(objectclass=*)
|
||||
For a connection to be known secure, SSL usage must be configured
|
||||
on <emphasis>both the client and the server</> before the connection
|
||||
is made. If it is only configured on the server, the client may end up
|
||||
sending sensitive information (e.g. passwords) before
|
||||
sending sensitive information (e.g., passwords) before
|
||||
it knows that the server requires high security. In libpq, secure
|
||||
connections can be ensured
|
||||
by setting the <literal>sslmode</> parameter to <literal>verify-full</> or
|
||||
|
@ -206,7 +206,7 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
|
||||
When the server shuts down cleanly, a permanent copy of the statistics
|
||||
data is stored in the <filename>pg_stat</filename> subdirectory, so that
|
||||
statistics can be retained across server restarts. When recovery is
|
||||
performed at server start (e.g. after immediate shutdown, server crash,
|
||||
performed at server start (e.g., after immediate shutdown, server crash,
|
||||
and point-in-time recovery), all statistics counters are reset.
|
||||
</para>
|
||||
|
||||
|
@ -269,7 +269,7 @@
|
||||
<para>
|
||||
In <productname>PostgreSQL</productname>, you can request any of
|
||||
the four standard transaction isolation levels, but internally only
|
||||
three distinct isolation levels are implemented, i.e. PostgreSQL's
|
||||
three distinct isolation levels are implemented, i.e., PostgreSQL's
|
||||
Read Uncommitted mode behaves like Read Committed. This is because
|
||||
it is the only sensible way to map the standard isolation levels to
|
||||
PostgreSQL's multiversion concurrency control architecture.
|
||||
|
@ -401,7 +401,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
|
||||
<xref linkend="guc-parallel-tuple-cost">. Of course, this plan may turn
|
||||
out to be slower than the serial plan which the planner preferred, but
|
||||
this will not always be the case. If you don't get a parallel
|
||||
plan even with very small values of these settings (e.g. after setting
|
||||
plan even with very small values of these settings (e.g., after setting
|
||||
them both to zero), there may be some reason why the query planner is
|
||||
unable to generate a parallel plan for your query. See
|
||||
<xref linkend="when-can-parallel-query-be-used"> and
|
||||
@ -493,7 +493,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
|
||||
<para>
|
||||
Functions and aggregates must be marked <literal>PARALLEL UNSAFE</> if
|
||||
they write to the database, access sequences, change the transaction state
|
||||
even temporarily (e.g. a PL/pgSQL function which establishes an
|
||||
even temporarily (e.g., a PL/pgSQL function which establishes an
|
||||
<literal>EXCEPTION</> block to catch errors), or make persistent changes to
|
||||
settings. Similarly, functions must be marked <literal>PARALLEL
|
||||
RESTRICTED</> if they access temporary tables, client connection state,
|
||||
|
@ -1808,7 +1808,7 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
|
||||
<listitem>
|
||||
<para>
|
||||
Place the database cluster's data directory in a memory-backed
|
||||
file system (i.e. <acronym>RAM</> disk). This eliminates all
|
||||
file system (i.e., <acronym>RAM</> disk). This eliminates all
|
||||
database disk I/O, but limits data storage to the amount of
|
||||
available memory (and perhaps swap).
|
||||
</para>
|
||||
|
@ -28,7 +28,7 @@
|
||||
the server, the connection will be rejected (for example, this would occur
|
||||
if the client requested protocol version 4.0, which does not exist as of
|
||||
this writing). If the minor version requested by the client is not
|
||||
supported by the server (e.g. the client requests version 3.1, but the
|
||||
supported by the server (e.g., the client requests version 3.1, but the
|
||||
server supports only 3.0), the server may either reject the connection or
|
||||
may respond with a NegotiateProtocolVersion message containing the highest
|
||||
minor protocol version which it supports. The client may then choose either
|
||||
@ -422,7 +422,7 @@
|
||||
by the client, but does support an earlier version of the protocol;
|
||||
this message indicates the highest supported minor version. This
|
||||
message will also be sent if the client requested unsupported protocol
|
||||
options (i.e. beginning with <literal>_pq_.</literal>) in the
|
||||
options (i.e., beginning with <literal>_pq_.</literal>) in the
|
||||
startup packet. This message will be followed by an ErrorResponse or
|
||||
a message indicating the success or failure of authentication.
|
||||
</para>
|
||||
|
@ -1256,7 +1256,7 @@ GROUPING SETS (
|
||||
( )
|
||||
)
|
||||
</programlisting>
|
||||
This is commonly used for analysis over hierarchical data; e.g. total
|
||||
This is commonly used for analysis over hierarchical data; e.g., total
|
||||
salary by department, division, and company-wide total.
|
||||
</para>
|
||||
|
||||
@ -1265,7 +1265,7 @@ GROUPING SETS (
|
||||
<programlisting>
|
||||
CUBE ( <replaceable>e1</>, <replaceable>e2</>, ... )
|
||||
</programlisting>
|
||||
represents the given list and all of its possible subsets (i.e. the power
|
||||
represents the given list and all of its possible subsets (i.e., the power
|
||||
set). Thus
|
||||
<programlisting>
|
||||
CUBE ( a, b, c )
|
||||
|
@ -173,7 +173,7 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
|
||||
<listitem>
|
||||
<para>
|
||||
This parameter specifies that recovery should end as soon as a
|
||||
consistent state is reached, i.e. as early as possible. When restoring
|
||||
consistent state is reached, i.e., as early as possible. When restoring
|
||||
from an online backup, this means the point where taking the backup
|
||||
ended.
|
||||
</para>
|
||||
|
@ -116,7 +116,7 @@ CREATE DATABASE <replaceable class="PARAMETER">name</replaceable>
|
||||
<listitem>
|
||||
<para>
|
||||
Collation order (<literal>LC_COLLATE</>) to use in the new database.
|
||||
This affects the sort order applied to strings, e.g. in queries with
|
||||
This affects the sort order applied to strings, e.g., in queries with
|
||||
ORDER BY, as well as the order used in indexes on text columns.
|
||||
The default is to use the collation order of the template database.
|
||||
See below for additional restrictions.
|
||||
@ -128,7 +128,7 @@ CREATE DATABASE <replaceable class="PARAMETER">name</replaceable>
|
||||
<listitem>
|
||||
<para>
|
||||
Character classification (<literal>LC_CTYPE</>) to use in the new
|
||||
database. This affects the categorization of characters, e.g. lower,
|
||||
database. This affects the categorization of characters, e.g., lower,
|
||||
upper and digit. The default is to use the character classification of
|
||||
the template database. See below for additional restrictions.
|
||||
</para>
|
||||
|
@ -86,7 +86,7 @@ CREATE EVENT TRIGGER <replaceable class="PARAMETER">name</replaceable>
|
||||
A list of values for the
|
||||
associated <replaceable class="parameter">filter_variable</replaceable>
|
||||
for which the trigger should fire. For <literal>TAG</>, this means a
|
||||
list of command tags (e.g. <literal>'DROP FUNCTION'</>).
|
||||
list of command tags (e.g., <literal>'DROP FUNCTION'</>).
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -257,7 +257,7 @@ CREATE [ OR REPLACE ] FUNCTION
|
||||
The name of the language that the function is implemented in.
|
||||
It can be <literal>sql</literal>, <literal>c</literal>,
|
||||
<literal>internal</literal>, or the name of a user-defined
|
||||
procedural language, e.g. <literal>plpgsql</literal>. Enclosing the
|
||||
procedural language, e.g., <literal>plpgsql</literal>. Enclosing the
|
||||
name in single quotes is deprecated and requires matching case.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -431,11 +431,11 @@ CREATE [ OR REPLACE ] FUNCTION
|
||||
Functions should be labeled parallel unsafe if they modify any database
|
||||
state, or if they make changes to the transaction such as using
|
||||
sub-transactions, or if they access sequences or attempt to make
|
||||
persistent changes to settings (e.g. <literal>setval</>). They should
|
||||
persistent changes to settings (e.g., <literal>setval</>). They should
|
||||
be labeled as parallel restricted if they access temporary tables,
|
||||
client connection state, cursors, prepared statements, or miscellaneous
|
||||
backend-local state which the system cannot synchronize in parallel mode
|
||||
(e.g. <literal>setseed</> cannot be executed other than by the group
|
||||
(e.g., <literal>setseed</> cannot be executed other than by the group
|
||||
leader because a change made by another process would not be reflected
|
||||
in the leader). In general, if a function is labeled as being safe when
|
||||
it is restricted or unsafe, or if it is labeled as being restricted when
|
||||
|
@ -129,7 +129,7 @@ CREATE STATISTICS [ IF NOT EXISTS ] <replaceable class="PARAMETER">statistics_na
|
||||
<title>Examples</title>
|
||||
|
||||
<para>
|
||||
Create table <structname>t1</> with two functionally dependent columns, i.e.
|
||||
Create table <structname>t1</> with two functionally dependent columns, i.e.,
|
||||
knowledge of a value in the first column is sufficient for determining the
|
||||
value in the other column. Then functional dependency statistics are built
|
||||
on those columns:
|
||||
|
@ -352,7 +352,7 @@ GRANT <replaceable class="PARAMETER">role_name</replaceable> [, ...] TO <replace
|
||||
schema (assuming that the objects' own privilege requirements are
|
||||
also met). Essentially this allows the grantee to <quote>look up</>
|
||||
objects within the schema. Without this permission, it is still
|
||||
possible to see the object names, e.g. by querying the system tables.
|
||||
possible to see the object names, e.g., by querying the system tables.
|
||||
Also, after revoking this permission, existing backends might have
|
||||
statements that have previously performed this lookup, so this is not
|
||||
a completely secure way to prevent object access.
|
||||
|
@ -80,7 +80,7 @@ PostgreSQL documentation
|
||||
<command>initdb</command> initializes the database cluster's default
|
||||
locale and character set encoding. The character set encoding,
|
||||
collation order (<literal>LC_COLLATE</>) and character set classes
|
||||
(<literal>LC_CTYPE</>, e.g. upper, lower, digit) can be set separately
|
||||
(<literal>LC_CTYPE</>, e.g., upper, lower, digit) can be set separately
|
||||
for a database when it is created. <command>initdb</command> determines
|
||||
those settings for the <literal>template1</literal> database, which will
|
||||
serve as the default for all other databases.
|
||||
|
@ -750,7 +750,7 @@ PostgreSQL documentation
|
||||
<term><option>--if-exists</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Use conditional commands (i.e. add an <literal>IF EXISTS</literal>
|
||||
Use conditional commands (i.e., add an <literal>IF EXISTS</literal>
|
||||
clause) when cleaning database objects. This option is not valid
|
||||
unless <option>--clean</> is also specified.
|
||||
</para>
|
||||
|
@ -295,7 +295,7 @@ PostgreSQL documentation
|
||||
<term><option>--if-exists</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Use conditional commands (i.e. add an <literal>IF EXISTS</literal>
|
||||
Use conditional commands (i.e., add an <literal>IF EXISTS</literal>
|
||||
clause) to clean databases and other objects. This option is not valid
|
||||
unless <option>--clean</> is also specified.
|
||||
</para>
|
||||
|
@ -555,7 +555,7 @@ PostgreSQL documentation
|
||||
<term><option>--if-exists</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Use conditional commands (i.e. add an <literal>IF EXISTS</literal>
|
||||
Use conditional commands (i.e., add an <literal>IF EXISTS</literal>
|
||||
clause) when cleaning database objects. This option is not valid
|
||||
unless <option>--clean</> is also specified.
|
||||
</para>
|
||||
|
@ -70,7 +70,7 @@ PostgreSQL documentation
|
||||
files might no longer be present. In that case, they can be manually
|
||||
copied from the WAL archive to the <filename>pg_wal</> directory, or
|
||||
fetched on startup by configuring <filename>recovery.conf</>. The use of
|
||||
<application>pg_rewind</> is not limited to failover, e.g. a standby
|
||||
<application>pg_rewind</> is not limited to failover, e.g., a standby
|
||||
server can be promoted, run some write transactions, and then rewinded
|
||||
to become a standby again.
|
||||
</para>
|
||||
|
@ -484,7 +484,7 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
|
||||
transaction to finish. The wait time is called the schedule lag time,
|
||||
and its average and maximum are also reported separately. The
|
||||
transaction latency with respect to the actual transaction start time,
|
||||
i.e. the time spent executing the transaction in the database, can be
|
||||
i.e., the time spent executing the transaction in the database, can be
|
||||
computed by subtracting the schedule lag time from the reported
|
||||
latency.
|
||||
</para>
|
||||
@ -617,7 +617,7 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
|
||||
<para>
|
||||
Remember to take the sampling rate into account when processing the
|
||||
log file. For example, when computing tps values, you need to multiply
|
||||
the numbers accordingly (e.g. with 0.01 sample rate, you'll only get
|
||||
the numbers accordingly (e.g., with 0.01 sample rate, you'll only get
|
||||
1/100 of the actual tps).
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1090,7 +1090,7 @@ f(x) = PHI(2.0 * parameter * (x - mu) / (max - min + 1)) /
|
||||
<literal>2.0 / parameter</>, that is a relative
|
||||
<literal>1.0 / parameter</> around the mean; for instance, if
|
||||
<replaceable>parameter</> is 4.0, 67% of values are drawn from the
|
||||
middle quarter (1.0 / 4.0) of the interval (i.e. from
|
||||
middle quarter (1.0 / 4.0) of the interval (i.e., from
|
||||
<literal>3.0 / 8.0</> to <literal>5.0 / 8.0</>) and 95% from
|
||||
the middle half (<literal>2.0 / 4.0</>) of the interval (second and third
|
||||
quartiles). The minimum <replaceable>parameter</> is 2.0 for performance
|
||||
@ -1235,7 +1235,7 @@ END;
|
||||
and <replaceable>max_lag</>, are only present if the <option>--rate</>
|
||||
option is used.
|
||||
They provide statistics about the time each transaction had to wait for the
|
||||
previous one to finish, i.e. the difference between each transaction's
|
||||
previous one to finish, i.e., the difference between each transaction's
|
||||
scheduled start time and the time it actually started.
|
||||
The very last field, <replaceable>skipped</>,
|
||||
is only present if the <option>--latency-limit</> option is used, too.
|
||||
|
@ -41,8 +41,8 @@ PostgreSQL documentation
|
||||
<application>pg_upgrade</> (formerly called <application>pg_migrator</>) allows data
|
||||
stored in <productname>PostgreSQL</> data files to be upgraded to a later <productname>PostgreSQL</>
|
||||
major version without the data dump/reload typically required for
|
||||
major version upgrades, e.g. from 9.5.8 to 9.6.4 or from 10.7 to 11.2.
|
||||
It is not required for minor version upgrades, e.g. from 9.6.2 to 9.6.3
|
||||
major version upgrades, e.g., from 9.5.8 to 9.6.4 or from 10.7 to 11.2.
|
||||
It is not required for minor version upgrades, e.g., from 9.6.2 to 9.6.3
|
||||
or from 10.1 to 10.2.
|
||||
</para>
|
||||
|
||||
@ -60,7 +60,7 @@ PostgreSQL documentation
|
||||
|
||||
<para>
|
||||
<application>pg_upgrade</> does its best to
|
||||
make sure the old and new clusters are binary-compatible, e.g. by
|
||||
make sure the old and new clusters are binary-compatible, e.g., by
|
||||
checking for compatible compile-time settings, including 32/64-bit
|
||||
binaries. It is important that
|
||||
any external modules are also binary compatible, though this cannot
|
||||
@ -209,13 +209,13 @@ PostgreSQL documentation
|
||||
<title>Optionally move the old cluster</title>
|
||||
|
||||
<para>
|
||||
If you are using a version-specific installation directory, e.g.
|
||||
If you are using a version-specific installation directory, e.g.,
|
||||
<filename>/opt/PostgreSQL/&majorversion;</>, you do not need to move the old cluster. The
|
||||
graphical installers all use version-specific installation directories.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If your installation directory is not version-specific, e.g.
|
||||
If your installation directory is not version-specific, e.g.,
|
||||
<filename>/usr/local/pgsql</>, it is necessary to move the current PostgreSQL install
|
||||
directory so it does not interfere with the new <productname>PostgreSQL</> installation.
|
||||
Once the current <productname>PostgreSQL</> server is shut down, it is safe to rename the
|
||||
@ -273,9 +273,9 @@ make prefix=/usr/local/pgsql.new install
|
||||
|
||||
<para>
|
||||
Install any custom shared object files (or DLLs) used by the old cluster
|
||||
into the new cluster, e.g. <filename>pgcrypto.so</filename>,
|
||||
into the new cluster, e.g., <filename>pgcrypto.so</filename>,
|
||||
whether they are from <filename>contrib</filename>
|
||||
or some other source. Do not install the schema definitions, e.g.
|
||||
or some other source. Do not install the schema definitions, e.g.,
|
||||
<command>CREATE EXTENSION pgcrypto</>, because these will be upgraded
|
||||
from the old cluster.
|
||||
Also, any custom full text search files (dictionary, synonym,
|
||||
@ -481,7 +481,7 @@ pg_upgrade.exe
|
||||
|
||||
<para>
|
||||
Save any configuration files from the old standbys' configuration
|
||||
directories you need to keep, e.g. <filename>postgresql.conf</filename>
|
||||
directories you need to keep, e.g., <filename>postgresql.conf</filename>
|
||||
(and any files included by it), <filename>postgresql.auto.conf</filename>,
|
||||
<literal>recovery.conf</literal>, <literal>pg_hba.conf</literal>,
|
||||
because these will be overwritten or removed in the next step.
|
||||
@ -508,7 +508,7 @@ rsync --archive --delete --hard-links --size-only --no-inc-recursive old_cluster
|
||||
on the standby. The directory structure under the specified
|
||||
directories on the primary and standbys must match. Consult the
|
||||
<application>rsync</> manual page for details on specifying the
|
||||
remote directory, e.g.
|
||||
remote directory, e.g.,
|
||||
|
||||
<programlisting>
|
||||
rsync --archive --delete --hard-links --size-only --no-inc-recursive /opt/PostgreSQL/9.5 \
|
||||
@ -634,7 +634,7 @@ psql --username=postgres --file=script.sql postgres
|
||||
<command>pg_upgrade</command> completes. (Automatic deletion is not
|
||||
possible if you have user-defined tablespaces inside the old data
|
||||
directory.) You can also delete the old installation directories
|
||||
(e.g. <filename>bin</>, <filename>share</>).
|
||||
(e.g., <filename>bin</>, <filename>share</>).
|
||||
</para>
|
||||
</step>
|
||||
|
||||
@ -734,7 +734,7 @@ psql --username=postgres --file=script.sql postgres
|
||||
If you are upgrading a pre-<productname>PostgreSQL</> 9.2 cluster
|
||||
that uses a configuration-file-only directory, you must pass the
|
||||
real data directory location to <application>pg_upgrade</>, and
|
||||
pass the configuration directory location to the server, e.g.
|
||||
pass the configuration directory location to the server, e.g.,
|
||||
<literal>-d /real-data-directory -o '-D /configuration-directory'</>.
|
||||
</para>
|
||||
|
||||
@ -755,7 +755,7 @@ psql --username=postgres --file=script.sql postgres
|
||||
copy with any changes to make it consistent. (<option>--checksum</>
|
||||
is necessary because <command>rsync</> only has file modification-time
|
||||
granularity of one second.) You might want to exclude some
|
||||
files, e.g. <filename>postmaster.pid</>, as documented in <xref
|
||||
files, e.g., <filename>postmaster.pid</>, as documented in <xref
|
||||
linkend="backup-lowlevel-base-backup">. If your file system supports
|
||||
file system snapshots or copy-on-write file copies, you can use that
|
||||
to make a backup of the old cluster and tablespaces, though the snapshot
|
||||
|
@ -822,7 +822,7 @@ PostgreSQL documentation
|
||||
|
||||
<para>
|
||||
To start <command>postgres</command> with a specific
|
||||
port, e.g. 1234:
|
||||
port, e.g., 1234:
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>postgres -p 1234</userinput>
|
||||
</screen>
|
||||
|
@ -73,7 +73,7 @@ PREPARE <replaceable class="PARAMETER">name</replaceable> [ ( <replaceable class
|
||||
Prepared statements potentially have the largest performance advantage
|
||||
when a single session is being used to execute a large number of similar
|
||||
statements. The performance difference will be particularly
|
||||
significant if the statements are complex to plan or rewrite, e.g.
|
||||
significant if the statements are complex to plan or rewrite, e.g.,
|
||||
if the query involves a join of many tables or requires
|
||||
the application of several rules. If the statement is relatively simple
|
||||
to plan and rewrite but relatively expensive to execute, the
|
||||
@ -154,7 +154,7 @@ PREPARE <replaceable class="PARAMETER">name</replaceable> [ ( <replaceable class
|
||||
|
||||
<para>
|
||||
To examine the query plan <productname>PostgreSQL</productname> is using
|
||||
for a prepared statement, use <xref linkend="sql-explain">, e.g.
|
||||
for a prepared statement, use <xref linkend="sql-explain">, e.g.,
|
||||
<command>EXPLAIN EXECUTE</>.
|
||||
If a generic plan is in use, it will contain parameter symbols
|
||||
<literal>$<replaceable>n</></literal>, while a custom plan will have the
|
||||
|
@ -624,7 +624,7 @@ EOF
|
||||
|
||||
<para>
|
||||
<application>psql</application> returns 0 to the shell if it
|
||||
finished normally, 1 if a fatal error of its own occurs (e.g. out of memory,
|
||||
finished normally, 1 if a fatal error of its own occurs (e.g., out of memory,
|
||||
file not found), 2 if the connection to the server went bad
|
||||
and the session was not interactive, and 3 if an error occurred in a
|
||||
script and the variable <varname>ON_ERROR_STOP</varname> was set.
|
||||
@ -2768,7 +2768,7 @@ lo_import 152801
|
||||
In <literal>latex-longtable</literal> format, this controls
|
||||
the proportional width of each column containing a left-aligned
|
||||
data type. It is specified as a whitespace-separated list of values,
|
||||
e.g. <literal>'0.2 0.2 0.6'</>. Unspecified output columns
|
||||
e.g., <literal>'0.2 0.2 0.6'</>. Unspecified output columns
|
||||
use the last specified value.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -4102,7 +4102,7 @@ testdb=> \set PROMPT1 '%[%033[1;33;40m%]%n@%/%R%[%033[0m%]%# '
|
||||
<application>psql</application> starts up. Tab-completion is also
|
||||
supported, although the completion logic makes no claim to be an
|
||||
<acronym>SQL</acronym> parser. The queries generated by tab-completion
|
||||
can also interfere with other SQL commands, e.g. <literal>SET
|
||||
can also interfere with other SQL commands, e.g., <literal>SET
|
||||
TRANSACTION ISOLATION LEVEL</>.
|
||||
If for some reason you do not like the tab completion, you
|
||||
can turn it off by putting this in a file named
|
||||
|
@ -7389,7 +7389,7 @@ Branch: REL9_4_STABLE [c7b96ba29] 2018-10-10 13:53:03 -0700
|
||||
-->
|
||||
<para>
|
||||
Fix logical decoding to handle cases where a mapped catalog table is
|
||||
repeatedly rewritten, e.g. by <literal>VACUUM FULL</literal>
|
||||
repeatedly rewritten, e.g., by <literal>VACUUM FULL</literal>
|
||||
(Andres Freund)
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -31,7 +31,7 @@
|
||||
which is what should be used to refer to the origin across systems, is
|
||||
free-form <type>text</type>. It should be used in a way that makes conflicts
|
||||
between replication origins created by different replication solutions
|
||||
unlikely; e.g. by prefixing the replication solution's name to it.
|
||||
unlikely; e.g., by prefixing the replication solution's name to it.
|
||||
The OID is used only to avoid having to store the long version
|
||||
in situations where space efficiency is important. It should never be shared
|
||||
across systems.
|
||||
@ -68,7 +68,7 @@
|
||||
manner. Replay progress for all replication origins can be seen in the
|
||||
<link linkend="view-pg-replication-origin-status">
|
||||
<structname>pg_replication_origin_status</structname>
|
||||
</link> view. An individual origin's progress, e.g. when resuming
|
||||
</link> view. An individual origin's progress, e.g., when resuming
|
||||
replication, can be acquired using
|
||||
<link linkend="pg-replication-origin-progress"><function>pg_replication_origin_progress()</function></link>
|
||||
for any origin or
|
||||
@ -86,7 +86,7 @@
|
||||
output plugin callbacks (see <xref linkend="logicaldecoding-output-plugin">)
|
||||
generated by the session is tagged with the replication origin of the
|
||||
generating session. This allows treating them differently in the output
|
||||
plugin, e.g. ignoring all but locally-originating rows. Additionally
|
||||
plugin, e.g., ignoring all but locally-originating rows. Additionally
|
||||
the <link linkend="logicaldecoding-output-plugin-filter-origin">
|
||||
<function>filter_by_origin_cb</function></link> callback can be used
|
||||
to filter the logical decoding change stream based on the
|
||||
|
@ -1946,7 +1946,7 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433
|
||||
be migrated in-place from one major <productname>PostgreSQL</>
|
||||
version to another. Upgrades can be performed in minutes,
|
||||
particularly with <option>--link</> mode. It requires steps similar to
|
||||
<application>pg_dumpall</> above, e.g. starting/stopping the server,
|
||||
<application>pg_dumpall</> above, e.g., starting/stopping the server,
|
||||
running <application>initdb</>. The <application>pg_upgrade</> <link
|
||||
linkend="pgupgrade">documentation</> outlines the necessary steps.
|
||||
</para>
|
||||
|
@ -527,7 +527,7 @@ UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;
|
||||
commands. <productname>SELinux</> provides a feature to allow trusted
|
||||
code to run using a security label different from that of the client,
|
||||
generally for the purpose of providing highly controlled access to
|
||||
sensitive data (e.g. rows might be omitted, or the precision of stored
|
||||
sensitive data (e.g., rows might be omitted, or the precision of stored
|
||||
values might be reduced). Whether or not a function acts as a trusted
|
||||
procedure is controlled by its security label and the operating system
|
||||
security policy. For example:
|
||||
|
@ -888,7 +888,7 @@ BETTER: unrecognized node type: 42
|
||||
<para>
|
||||
Both, macros with arguments and <literal>static inline</>
|
||||
functions, may be used. The latter are preferable if there are
|
||||
multiple-evaluation hazards when written as a macro, as e.g. the
|
||||
multiple-evaluation hazards when written as a macro, as e.g., the
|
||||
case with
|
||||
<programlisting>
|
||||
#define Max(x, y) ((x) > (y) ? (x) : (y))
|
||||
@ -899,7 +899,7 @@ BETTER: unrecognized node type: 42
|
||||
</para>
|
||||
<para>
|
||||
When the definition of an inline function references symbols
|
||||
(i.e. variables, functions) that are only available as part of the
|
||||
(i.e., variables, functions) that are only available as part of the
|
||||
backend, the function may not be visible when included from frontend
|
||||
code.
|
||||
<programlisting>
|
||||
|
@ -47,7 +47,7 @@
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Returns the name of the protocol used for the SSL connection (e.g. TLSv1.0
|
||||
Returns the name of the protocol used for the SSL connection (e.g., TLSv1.0
|
||||
TLSv1.1, or TLSv1.2).
|
||||
</para>
|
||||
</listitem>
|
||||
@ -63,7 +63,7 @@
|
||||
<listitem>
|
||||
<para>
|
||||
Returns the name of the cipher used for the SSL connection
|
||||
(e.g. DHE-RSA-AES256-SHA).
|
||||
(e.g., DHE-RSA-AES256-SHA).
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -266,7 +266,7 @@
|
||||
overhead can reduce performance, especially if journaling
|
||||
causes file system <emphasis>data</emphasis> to be flushed
|
||||
to disk. Fortunately, data flushing during journaling can
|
||||
often be disabled with a file system mount option, e.g.
|
||||
often be disabled with a file system mount option, e.g.,
|
||||
<literal>data=writeback</> on a Linux ext3 file system.
|
||||
Journaled file systems do improve boot speed after a crash.
|
||||
</para>
|
||||
|
@ -116,9 +116,9 @@
|
||||
Besides <command>SELECT</command> queries, the commands can include data
|
||||
modification queries (<command>INSERT</command>,
|
||||
<command>UPDATE</command>, and <command>DELETE</command>), as well as
|
||||
other SQL commands. (You cannot use transaction control commands, e.g.
|
||||
other SQL commands. (You cannot use transaction control commands, e.g.,
|
||||
<command>COMMIT</>, <command>SAVEPOINT</>, and some utility
|
||||
commands, e.g. <literal>VACUUM</>, in <acronym>SQL</acronym> functions.)
|
||||
commands, e.g., <literal>VACUUM</>, in <acronym>SQL</acronym> functions.)
|
||||
However, the final command
|
||||
must be a <command>SELECT</command> or have a <literal>RETURNING</>
|
||||
clause that returns whatever is
|
||||
@ -3363,7 +3363,7 @@ if (!ptr)
|
||||
exceptions. Any exceptions must be caught and appropriate errors
|
||||
passed back to the C interface. If possible, compile C++ with
|
||||
<option>-fno-exceptions</> to eliminate exceptions entirely; in such
|
||||
cases, you must check for failures in your C++ code, e.g. check for
|
||||
cases, you must check for failures in your C++ code, e.g., check for
|
||||
NULL returned by <function>new()</>.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -327,7 +327,7 @@ AS t(article_id integer, author text, page_count integer, title text);
|
||||
The calling <command>SELECT</> statement doesn't necessarily have to be
|
||||
just <literal>SELECT *</> — it can reference the output
|
||||
columns by name or join them to other tables. The function produces a
|
||||
virtual table with which you can perform any operation you wish (e.g.
|
||||
virtual table with which you can perform any operation you wish (e.g.,
|
||||
aggregation, joining, sorting etc). So we could also have:
|
||||
<programlisting>
|
||||
SELECT t.title, p.fullname, p.email
|
||||
|
Loading…
x
Reference in New Issue
Block a user