Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 8442a92

Browse files
peterepetere
committed
Spell checking, consistent terminology.
1 parent 4240d2b commit 8442a92

36 files changed

+877
-870
lines changed

‎doc/src/sgml/arch-dev.sgml

+21-21
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
<!--
2-
$Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.22 2003/09/29 18:18:35 momjian Exp $
2+
$Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.23 2003/11/01 01:56:28 petere Exp $
33
-->
44

55
<chapter id="overview">
@@ -99,11 +99,11 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.22 2003/09/29 18:18:35 mo
9999
<para>
100100
The executor recursively steps through
101101
the <firstterm>plan tree</firstterm> and
102-
retrieves tuples in the way represented by the plan.
102+
retrieves rows in the way represented by the plan.
103103
The executor makes use of the
104104
<firstterm>storage system</firstterm> while scanning
105105
relations, performs <firstterm>sorts</firstterm> and <firstterm>joins</firstterm>,
106-
evaluates <firstterm>qualifications</firstterm> and finally hands back the tuples derived.
106+
evaluates <firstterm>qualifications</firstterm> and finally hands back the rows derived.
107107
</para>
108108
</step>
109109
</procedure>
@@ -150,7 +150,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.22 2003/09/29 18:18:35 mo
150150
to the <firstterm>backend</firstterm> (server). The query is transmitted using plain text,
151151
i.e. there is no parsing done in the <firstterm>frontend</firstterm> (client). The
152152
server parses the query, creates an <firstterm>execution plan</firstterm>,
153-
executes the plan and returns the retrieved tuples to the client
153+
executes the plan and returns the retrieved rows to the client
154154
by transmitting them over the established connection.
155155
</para>
156156
</sect1>
@@ -195,8 +195,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.22 2003/09/29 18:18:35 mo
195195
The <firstterm>lexer</firstterm> is defined in the file
196196
<filename>scan.l</filename> and is responsible
197197
for recognizing <firstterm>identifiers</firstterm>,
198-
the <firstterm>SQL keywords</firstterm> etc. For
199-
every keyword or identifier that is found, a <firstterm>token</firstterm>
198+
the <firstterm>SQL key words</firstterm> etc. For
199+
every key word or identifier that is found, a <firstterm>token</firstterm>
200200
is generated and handed to the parser.
201201
</para>
202202

@@ -278,7 +278,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.22 2003/09/29 18:18:35 mo
278278
call. This may be transformed to either a <structname>FuncExpr</>
279279
or <structname>Aggref</> node depending on whether the referenced
280280
name turns out to be an ordinary function or an aggregate function.
281-
Also, information about the actual datatypes of columns and expression
281+
Also, information about the actual data types of columns and expression
282282
results is added to the query tree.
283283
</para>
284284
</sect2>
@@ -297,9 +297,9 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.22 2003/09/29 18:18:35 mo
297297
<itemizedlist>
298298
<listitem>
299299
<para>
300-
The first one worked using <firstterm>tuple level</firstterm> processing and was
300+
The first one worked using <firstterm>row level</firstterm> processing and was
301301
implemented deep in the <firstterm>executor</firstterm>. The rule system was
302-
called whenever an individual tuple had been accessed. This
302+
called whenever an individual row had been accessed. This
303303
implementation was removed in 1995 when the last official release
304304
of the <productname>Berkeley Postgres</productname> project was
305305
transformed into <productname>Postgres95</productname>.
@@ -396,11 +396,11 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.22 2003/09/29 18:18:35 mo
396396
<listitem>
397397
<para>
398398
<firstterm>nested loop join</firstterm>: The right relation is scanned
399-
once for every tuple found in the left relation. This strategy
399+
once for every row found in the left relation. This strategy
400400
is easy to implement but can be very time consuming. (However,
401-
if the right relation can be scanned with an indexscan, this can
401+
if the right relation can be scanned with an index scan, this can
402402
be a good strategy. It is possible to use values from the current
403-
row of the left relation as keys for the indexscan of the right.)
403+
row of the left relation as keys for the index scan of the right.)
404404
</para>
405405
</listitem>
406406

@@ -419,16 +419,16 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.22 2003/09/29 18:18:35 mo
419419
<firstterm>hash join</firstterm>: the right relation is first scanned
420420
and loaded into a hash table, using its join attributes as hash keys.
421421
Next the left relation is scanned and the
422-
appropriate values of every tuple found are used as hash keys to
423-
locate the matching tuples in the table.
422+
appropriate values of every row found are used as hash keys to
423+
locate the matching rows in the table.
424424
</para>
425425
</listitem>
426426
</itemizedlist>
427427
</para>
428428

429429
<para>
430430
The finished plan tree consists of sequential or index scans of
431-
the base relations, plus nestloop, merge, or hash join nodes as
431+
the base relations, plus nested-loop, merge, or hash join nodes as
432432
needed, plus any auxiliary steps needed, such as sort nodes or
433433
aggregate-function calculation nodes. Most of these plan node
434434
types have the additional ability to do <firstterm>selection</>
@@ -451,26 +451,26 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.22 2003/09/29 18:18:35 mo
451451
The <firstterm>executor</firstterm> takes the plan handed back by the
452452
planner/optimizer and recursively processes it to extract the required set
453453
of rows. This is essentially a demand-pull pipeline mechanism.
454-
Each time a plan node is called, it must deliver one more tuple, or
455-
report that it is done delivering tuples.
454+
Each time a plan node is called, it must deliver one more row, or
455+
report that it is done delivering rows.
456456
</para>
457457

458458
<para>
459459
To provide a concrete example, assume that the top
460460
node is a <literal>MergeJoin</literal> node.
461-
Before any merge can be done two tuples have to be fetched (one from
461+
Before any merge can be done two rows have to be fetched (one from
462462
each subplan). So the executor recursively calls itself to
463463
process the subplans (it starts with the subplan attached to
464464
<literal>lefttree</literal>). The new top node (the top node of the left
465465
subplan) is, let's say, a
466466
<literal>Sort</literal> node and again recursion is needed to obtain
467-
an input tuple. The child node of the <literal>Sort</literal> might
467+
an input row. The child node of the <literal>Sort</literal> might
468468
be a <literal>SeqScan</> node, representing actual reading of a table.
469469
Execution of this node causes the executor to fetch a row from the
470470
table and return it up to the calling node. The <literal>Sort</literal>
471471
node will repeatedly call its child to obtain all the rows to be sorted.
472472
When the input is exhausted (as indicated by the child node returning
473-
a NULL instead of a tuple), the <literal>Sort</literal> code performs
473+
a NULL instead of a row), the <literal>Sort</literal> code performs
474474
the sort, and finally is able to return its first output row, namely
475475
the first one in sorted order. It keeps the remaining rows stored so
476476
that it can deliver them in sorted order in response to later demands.
@@ -508,7 +508,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.22 2003/09/29 18:18:35 mo
508508
result row. But <command>INSERT ... SELECT</> may demand the full power
509509
of the executor mechanism.) For <command>UPDATE</>, the planner arranges
510510
that each computed row includes all the updated column values, plus
511-
the <firstterm>TID</> (tuple ID, or location) of the original target row;
511+
the <firstterm>TID</> (tuple ID, or row ID) of the original target row;
512512
the executor top level uses this information to create a new updated row
513513
and mark the old row deleted. For <command>DELETE</>, the only column
514514
that is actually returned by the plan is the TID, and the executor top

‎doc/src/sgml/array.sgml

+6-6
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/array.sgml,v 1.31 2003/08/31 17:32:18 petere Exp $ -->
1+
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/array.sgml,v 1.32 2003/11/01 01:56:28 petere Exp $ -->
22

33
<sect1 id="arrays">
44
<title>Arrays</title>
@@ -348,9 +348,9 @@ SELECT ARRAY[5,6] || ARRAY[[1,2],[3,4]];
348348
<para>
349349
When a single element is pushed on to the beginning of a one-dimensional
350350
array, the result is an array with a lower bound subscript equal to
351-
the righthand operand's lower bound subscript, minus one. When a single
351+
the right-hand operand's lower bound subscript, minus one. When a single
352352
element is pushed on to the end of a one-dimensional array, the result is
353-
an array retaining the lower bound of the lefthand operand. For example:
353+
an array retaining the lower bound of the left-hand operand. For example:
354354
<programlisting>
355355
SELECT array_dims(1 || ARRAY[2,3]);
356356
array_dims
@@ -368,9 +368,9 @@ SELECT array_dims(ARRAY[1,2] || 3);
368368

369369
<para>
370370
When two arrays with an equal number of dimensions are concatenated, the
371-
result retains the lower bound subscript of the lefthand operand's outer
372-
dimension. The result is an array comprising every element of the lefthand
373-
operand followed by every element of the righthand operand. For example:
371+
result retains the lower bound subscript of the left-hand operand's outer
372+
dimension. The result is an array comprising every element of the left-hand
373+
operand followed by every element of the right-hand operand. For example:
374374
<programlisting>
375375
SELECT array_dims(ARRAY[1,2] || ARRAY[3,4,5]);
376376
array_dims

‎doc/src/sgml/catalogs.sgml

+15-15
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
<!--
22
Documentation of the system catalogs, directed toward PostgreSQL developers
3-
$Header: /cvsroot/pgsql/doc/src/sgml/catalogs.sgml,v 2.76 2003/10/17 22:38:20 tgl Exp $
3+
$Header: /cvsroot/pgsql/doc/src/sgml/catalogs.sgml,v 2.77 2003/11/01 01:56:28 petere Exp $
44
-->
55

66
<chapter id="catalogs">
@@ -755,9 +755,9 @@
755755
<entry><type>int4</type></entry>
756756
<entry></entry>
757757
<entry>
758-
Always -1 in storage, but when loaded into a tuple descriptor
758+
Always -1 in storage, but when loaded into a row descriptor
759759
in memory this may be updated to cache the offset of the attribute
760-
within the tuple.
760+
within the row.
761761
</entry>
762762
</row>
763763

@@ -800,9 +800,9 @@
800800
<entry></entry>
801801
<entry>
802802
If true, this attribute is a set. In that case, what is really
803-
stored in the attribute is the OID of a tuple in the
803+
stored in the attribute is the OID of a row in the
804804
<structname>pg_proc</structname> catalog. The
805-
<structname>pg_proc</structname> tuple contains the query
805+
<structname>pg_proc</structname> row contains the query
806806
string that defines this set, i.e., the query to run to get
807807
the set. So the <structfield>atttypid</structfield> (see
808808
above) refers to the type returned by this query, but the
@@ -1046,7 +1046,7 @@
10461046
<entry><type>float4</type></entry>
10471047
<entry></entry>
10481048
<entry>
1049-
Number of tuples in the table.
1049+
Number of rows in the table.
10501050
This is only an estimate used by the planner.
10511051
It is updated by <command>VACUUM</command>,
10521052
<command>ANALYZE</command>, and <command>CREATE INDEX</command>.
@@ -1553,7 +1553,7 @@
15531553
<entry><type>xid</type></entry>
15541554
<entry></entry>
15551555
<entry>
1556-
All tuples inserted or deleted by transaction IDs before this one
1556+
All rows inserted or deleted by transaction IDs before this one
15571557
have been marked as known committed or known aborted in this database.
15581558
This is used to determine when commit-log space can be recycled.
15591559
</entry>
@@ -1564,7 +1564,7 @@
15641564
<entry><type>xid</type></entry>
15651565
<entry></entry>
15661566
<entry>
1567-
All tuples inserted by transaction IDs before this one have been
1567+
All rows inserted by transaction IDs before this one have been
15681568
relabeled with a permanent (<quote>frozen</>) transaction ID in this
15691569
database. This is useful to check whether a database must be vacuumed
15701570
soon to avoid transaction ID wrap-around problems.
@@ -1666,7 +1666,7 @@
16661666
<row>
16671667
<entry><structfield>refobjid</structfield></entry>
16681668
<entry><type>oid</type></entry>
1669-
<entry>any oid attribute</entry>
1669+
<entry>any OID column</entry>
16701670
<entry>The OID of the specific referenced object</entry>
16711671
</row>
16721672

@@ -1945,7 +1945,7 @@
19451945
<row>
19461946
<entry><structfield>indkey</structfield></entry>
19471947
<entry><type>int2vector</type></entry>
1948-
<entry><link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.attnum</entry>
1948+
<entry><literal><link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.attnum</literal></entry>
19491949
<entry>
19501950
This is an array of <structfield>indnatts</structfield> (up to
19511951
<symbol>INDEX_MAX_KEYS</symbol>) values that indicate which
@@ -2407,7 +2407,7 @@
24072407
<entry><structfield>opcamid</structfield></entry>
24082408
<entry><type>oid</type></entry>
24092409
<entry><literal><link linkend="catalog-pg-am"><structname>pg_am</structname></link>.oid</literal></entry>
2410-
<entry>Index access method opclass is for</entry>
2410+
<entry>Index access method operator class is for</entry>
24112411
</row>
24122412

24132413
<row>
@@ -3233,7 +3233,7 @@
32333233
<entry><structfield>tgtype</structfield></entry>
32343234
<entry><type>int2</type></entry>
32353235
<entry></entry>
3236-
<entry>Bitmask identifying trigger conditions</entry>
3236+
<entry>Bit mask identifying trigger conditions</entry>
32373237
</row>
32383238

32393239
<row>
@@ -3534,7 +3534,7 @@
35343534
For types used in system tables, it is critical that the size
35353535
and alignment defined in <structname>pg_type</structname>
35363536
agree with the way that the compiler will lay out the column in
3537-
a struct representing a table row.
3537+
a structure representing a table row.
35383538
</para>
35393539
</note></entry>
35403540
</row>
@@ -3611,8 +3611,8 @@
36113611
<entry></entry>
36123612
<entry><para>
36133613
<structfield>typndims</structfield> is the number of array dimensions
3614-
for a domain that is an array (that is, typbasetype is an array type;
3615-
the domain's typelem will match the base type's typelem).
3614+
for a domain that is an array (that is, <structfield>typbasetype</> is an array type;
3615+
the domain's <structfield>typelem</> will match the base type's <structfield>typelem</structfield>).
36163616
Zero for types other than array domains.
36173617
</para></entry>
36183618
</row>

0 commit comments

Comments
 (0)