Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitc3d583d

Browse files
committed
More updates and copy-editing. Rearrange order of sections a little bit
to put more widely useful info before less widely useful info.
1 parent1ade4b3 commitc3d583d

File tree

6 files changed

+653
-596
lines changed

6 files changed

+653
-596
lines changed

‎doc/src/sgml/extend.sgml‎

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
<!--
2-
$PostgreSQL: pgsql/doc/src/sgml/extend.sgml,v 1.28 2004/06/07 04:04:47 tgl Exp $
2+
$PostgreSQL: pgsql/doc/src/sgml/extend.sgml,v 1.29 2004/12/30 03:13:56 tgl Exp $
33
-->
44

55
<chapter id="extend">
@@ -152,8 +152,8 @@ $PostgreSQL: pgsql/doc/src/sgml/extend.sgml,v 1.28 2004/06/07 04:04:47 tgl Exp $
152152

153153
<para>
154154
Domains can be created using the <acronym>SQL</> command
155-
<command>CREATE DOMAIN</command>. Their creation and use is not
156-
discussed in this chapter.
155+
<xref linkend="sql-createdomain" endterm="sql-createdomain-title">.
156+
Their creation and use is notdiscussed in this chapter.
157157
</para>
158158
</sect2>
159159

@@ -221,7 +221,7 @@ $PostgreSQL: pgsql/doc/src/sgml/extend.sgml,v 1.28 2004/06/07 04:04:47 tgl Exp $
221221
Thus, when more than one argument position is declared with a polymorphic
222222
type, the net effect is that only certain combinations of actual argument
223223
types are allowed. For example, a function declared as
224-
<literal>foo(anyelement, anyelement)</> will take any two input values,
224+
<literal>equal(anyelement, anyelement)</> will take any two input values,
225225
so long as they are of the same data type.
226226
</para>
227227

‎doc/src/sgml/postgres.sgml‎

Lines changed: 7 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
<!--
2-
$PostgreSQL: pgsql/doc/src/sgml/postgres.sgml,v 1.71 2004/12/29 23:36:47 tgl Exp $
2+
$PostgreSQL: pgsql/doc/src/sgml/postgres.sgml,v 1.72 2004/12/30 03:13:56 tgl Exp $
33
-->
44

55
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.2//EN" [
@@ -192,18 +192,19 @@ $PostgreSQL: pgsql/doc/src/sgml/postgres.sgml,v 1.71 2004/12/29 23:36:47 tgl Exp
192192
user-defined functions, data types, triggers, etc. These are
193193
advanced topics which should probably be approached only after all
194194
the other user documentation about <productname>PostgreSQL</> has
195-
been understood.This part also describes the server-side
195+
been understood.Later chapters in this part describe the server-side
196196
programming languages available in the
197197
<productname>PostgreSQL</productname> distribution as well as
198-
general issues concerning server-side programming languages. This
199-
information is only useful to readers that have read at least the
200-
first few chapters of this part.
198+
general issues concerning server-side programming languages. It
199+
is essential to read at least the earlier sections of <xref
200+
linkend="extend"> (covering functions) before diving into the
201+
material about server-side programming languages.
201202
</para>
202203
</partintro>
203204

204205
&extend;
205-
&rules;
206206
&trigger;
207+
&rules;
207208

208209
&xplang;
209210
&plsql;

‎doc/src/sgml/rules.sgml‎

Lines changed: 101 additions & 100 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/rules.sgml,v 1.36 2004/11/15 06:32:14 neilc Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/rules.sgml,v 1.37 2004/12/30 03:13:56 tgl Exp $ -->
22

33
<Chapter Id="rules">
44
<Title>The Rule System</Title>
@@ -104,19 +104,19 @@
104104
<ListItem>
105105
<Para>
106106
The range table is a list of relations that are used in the query.
107-
In a <command>SELECT</command> statement these are the relations given after
108-
the <literal>FROM</literal> key word.
107+
In a <command>SELECT</command> statement these are the relations given after
108+
the <literal>FROM</literal> key word.
109109
</Para>
110110

111111
<Para>
112112
Every range table entry identifies a table or view and tells
113-
by which name it is called in the other parts of the query.
114-
In the query tree, the range table entries are referenced by
115-
number rather than by name, so here it doesn't matter if there
116-
are duplicate names as it would in an <Acronym>SQL</Acronym>
117-
statement. This can happen after the range tables of rules
118-
have been merged in. The examples in this chapter will not have
119-
this situation.
113+
by which name it is called in the other parts of the query.
114+
In the query tree, the range table entries are referenced by
115+
number rather than by name, so here it doesn't matter if there
116+
are duplicate names as it would in an <Acronym>SQL</Acronym>
117+
statement. This can happen after the range tables of rules
118+
have been merged in. The examples in this chapter will not have
119+
this situation.
120120
</Para>
121121
</ListItem>
122122
</VarListEntry>
@@ -128,21 +128,21 @@
128128
<ListItem>
129129
<Para>
130130
This is an index into the range table that identifies the
131-
relation where the results of the query go.
131+
relation where the results of the query go.
132132
</Para>
133133

134134
<Para>
135-
<command>SELECT</command> queries normally don't have a result
136-
relation. The special case of a <command>SELECT INTO</command> is
137-
mostly identical to a <command>CREATE TABLE</command> followed by a
138-
<literal>INSERT ... SELECT</literal> and is not discussed
139-
separately here.
135+
<command>SELECT</command> queries normally don't have a result
136+
relation. The special case of a <command>SELECT INTO</command> is
137+
mostly identical to a <command>CREATE TABLE</command> followed by a
138+
<literal>INSERT ... SELECT</literal> and is not discussed
139+
separately here.
140140
</Para>
141141

142142
<Para>
143143
For <command>INSERT</command>, <command>UPDATE</command>, and
144-
<command>DELETE</command> commands, the result relation is the table
145-
(or view!) where the changes take effect.
144+
<command>DELETE</command> commands, the result relation is the table
145+
(or view!) where the changes are to take effect.
146146
</Para>
147147
</ListItem>
148148
</VarListEntry>
@@ -167,39 +167,39 @@
167167

168168
<Para>
169169
<command>DELETE</command> commands don't need a target list
170-
because they don't produce any result. In fact, the planner will
171-
add a special <acronym>CTID</> entry to the empty target list, but
172-
this is after the rule system and will be discussed later; for the
173-
rule system, the target list is empty.
170+
because they don't produce any result. In fact, the planner will
171+
add a special <acronym>CTID</> entry to the empty target list, but
172+
this is after the rule system and will be discussed later; for the
173+
rule system, the target list is empty.
174174
</Para>
175175

176176
<Para>
177177
For <command>INSERT</command> commands, the target list describes
178-
the new rows that should go into the result relation. It consists of the
179-
expressions in the <literal>VALUES</> clause or the ones from the
180-
<command>SELECT</command> clause in <literal>INSERT
181-
... SELECT</literal>. The first step of the rewrite process adds
182-
target list entries for any columns that were not assigned to by
183-
the original command but have defaults. Any remaining columns (with
184-
neither a given value nor a default) will be filled in by the
185-
planner with a constant null expression.
178+
the new rows that should go into the result relation. It consists of the
179+
expressions in the <literal>VALUES</> clause or the ones from the
180+
<command>SELECT</command> clause in <literal>INSERT
181+
... SELECT</literal>. The first step of the rewrite process adds
182+
target list entries for any columns that were not assigned to by
183+
the original command but have defaults. Any remaining columns (with
184+
neither a given value nor a default) will be filled in by the
185+
planner with a constant null expression.
186186
</Para>
187187

188188
<Para>
189189
For <command>UPDATE</command> commands, the target list
190-
describes the new rows that should replace the old ones. In the
191-
rule system, it contains just the expressions from the <literal>SET
192-
column = expression</literal> part of the command. The planner will handle
193-
missing columns by inserting expressions that copy the values from
194-
the old row into the new one. And it will add the special
195-
<acronym>CTID</> entry just as for <command>DELETE</command>, too.
190+
describes the new rows that should replace the old ones. In the
191+
rule system, it contains just the expressions from the <literal>SET
192+
column = expression</literal> part of the command. The planner will handle
193+
missing columns by inserting expressions that copy the values from
194+
the old row into the new one. And it will add the special
195+
<acronym>CTID</> entry just as for <command>DELETE</command>, too.
196196
</Para>
197197

198198
<Para>
199199
Every entry in the target list contains an expression that can
200-
be a constant value, a variable pointing to a column of one
201-
of the relations in the range table, a parameter, or an expression
202-
tree made of function calls, constants, variables, operators, etc.
200+
be a constant value, a variable pointing to a column of one
201+
of the relations in the range table, a parameter, or an expression
202+
tree made of function calls, constants, variables, operators, etc.
203203
</Para>
204204
</ListItem>
205205
</VarListEntry>
@@ -211,12 +211,12 @@
211211
<ListItem>
212212
<Para>
213213
The query's qualification is an expression much like one of
214-
those contained in the target list entries. The result value of
215-
this expression is a Boolean that tells whether the operation
216-
(<command>INSERT</command>, <command>UPDATE</command>,
217-
<command>DELETE</command>, or <command>SELECT</command>) for the
218-
final result row should be executed or not. It corresponds to the <literal>WHERE</> clause
219-
of an <Acronym>SQL</Acronym> statement.
214+
those contained in the target list entries. The result value of
215+
this expression is a Boolean that tells whether the operation
216+
(<command>INSERT</command>, <command>UPDATE</command>,
217+
<command>DELETE</command>, or <command>SELECT</command>) for the
218+
final result row should be executed or not. It corresponds to the <literal>WHERE</> clause
219+
of an <Acronym>SQL</Acronym> statement.
220220
</Para>
221221
</ListItem>
222222
</VarListEntry>
@@ -228,17 +228,17 @@
228228
<ListItem>
229229
<Para>
230230
The query's join tree shows the structure of the <literal>FROM</> clause.
231-
For a simple query like <literal>SELECT ... FROM a, b, c</literal>, the join tree is just
232-
a list of the <literal>FROM</> items, because we are allowed to join them in
233-
any order. But when <literal>JOIN</> expressions, particularly outer joins,
234-
are used, we have to join in the order shown by the joins.
235-
In that case, the join tree shows the structure of the <literal>JOIN</> expressions. The
236-
restrictions associated with particular <literal>JOIN</> clauses (from <literal>ON</> or
237-
<literal>USING</> expressions) are stored as qualification expressions attached
238-
to those join-tree nodes. It turns out to be convenient to store
239-
the top-level <literal>WHERE</> expression as a qualification attached to the
240-
top-level join-tree item, too. So really the join tree represents
241-
both the <literal>FROM</> and <literal>WHERE</> clauses of a <command>SELECT</command>.
231+
For a simple query like <literal>SELECT ... FROM a, b, c</literal>, the join tree is just
232+
a list of the <literal>FROM</> items, because we are allowed to join them in
233+
any order. But when <literal>JOIN</> expressions, particularly outer joins,
234+
are used, we have to join in the order shown by the joins.
235+
In that case, the join tree shows the structure of the <literal>JOIN</> expressions. The
236+
restrictions associated with particular <literal>JOIN</> clauses (from <literal>ON</> or
237+
<literal>USING</> expressions) are stored as qualification expressions attached
238+
to those join-tree nodes. It turns out to be convenient to store
239+
the top-level <literal>WHERE</> expression as a qualification attached to the
240+
top-level join-tree item, too. So really the join tree represents
241+
both the <literal>FROM</> and <literal>WHERE</> clauses of a <command>SELECT</command>.
242242
</Para>
243243
</ListItem>
244244
</VarListEntry>
@@ -250,10 +250,10 @@
250250
<ListItem>
251251
<Para>
252252
The other parts of the query tree like the <literal>ORDER BY</>
253-
clause aren't of interest here. The rule system
254-
substitutes some entries there while applying rules, but that
255-
doesn't have much to do with the fundamentals of the rule
256-
system.
253+
clause aren't of interest here. The rule system
254+
substitutes some entries there while applying rules, but that
255+
doesn't have much to do with the fundamentals of the rule
256+
system.
257257
</Para>
258258
</ListItem>
259259
</VarListEntry>
@@ -322,7 +322,7 @@ CREATE RULE "_RETURN" AS ON SELECT TO myview DO INSTEAD
322322
Currently, there can be only one action in an <literal>ON SELECT</> rule, and it must
323323
be an unconditional <command>SELECT</> action that is <literal>INSTEAD</>. This restriction was
324324
required to make rules safe enough to open them for ordinary users, and
325-
it restricts <literal>ON SELECT</> rules toreal view rules.
325+
it restricts <literal>ON SELECT</> rules toact like views.
326326
</Para>
327327

328328
<Para>
@@ -695,29 +695,29 @@ UPDATE t1 SET b = t2.b WHERE t1.a = t2.a;
695695

696696
<ItemizedList>
697697
<ListItem>
698-
<Para>
699-
The range tables contain entries for the tables <literal>t1</> and <literal>t2</>.
700-
</Para>
698+
<Para>
699+
The range tables contain entries for the tables <literal>t1</> and <literal>t2</>.
700+
</Para>
701701
</ListItem>
702702

703703
<ListItem>
704-
<Para>
705-
The target lists contain one variable that points to column
706-
<literal>b</> of the range table entry for table <literal>t2</>.
707-
</Para>
704+
<Para>
705+
The target lists contain one variable that points to column
706+
<literal>b</> of the range table entry for table <literal>t2</>.
707+
</Para>
708708
</ListItem>
709709

710710
<ListItem>
711-
<Para>
712-
The qualification expressions compare the columns <literal>a</> of both
713-
range-table entries for equality.
714-
</Para>
711+
<Para>
712+
The qualification expressions compare the columns <literal>a</> of both
713+
range-table entries for equality.
714+
</Para>
715715
</ListItem>
716716

717717
<ListItem>
718-
<Para>
719-
The join trees show a simple join between <literal>t1</> and <literal>t2</>.
720-
</Para>
718+
<Para>
719+
The join trees show a simple join between <literal>t1</> and <literal>t2</>.
720+
</Para>
721721
</ListItem>
722722
</ItemizedList>
723723
</para>
@@ -860,34 +860,34 @@ SELECT t1.a, t2.b, t1.ctid FROM t1, t2 WHERE t1.a = t2.a;
860860

861861
<ItemizedList>
862862
<ListItem>
863-
<Para>
864-
They are allowed to have no action.
865-
</Para>
866-
</ListItem>
863+
<Para>
864+
They are allowed to have no action.
865+
</Para>
866+
</ListItem>
867867

868868
<ListItem>
869-
<Para>
870-
They can have multiple actions.
871-
</Para>
872-
</ListItem>
869+
<Para>
870+
They can have multiple actions.
871+
</Para>
872+
</ListItem>
873873

874874
<ListItem>
875-
<Para>
876-
They can be <literal>INSTEAD</> or <literal>ALSO</> (default).
877-
</Para>
878-
</ListItem>
875+
<Para>
876+
They can be <literal>INSTEAD</> or <literal>ALSO</> (default).
877+
</Para>
878+
</ListItem>
879879

880880
<ListItem>
881-
<Para>
882-
The pseudorelations <literal>NEW</> and <literal>OLD</> become useful.
883-
</Para>
884-
</ListItem>
881+
<Para>
882+
The pseudorelations <literal>NEW</> and <literal>OLD</> become useful.
883+
</Para>
884+
</ListItem>
885885

886886
<ListItem>
887-
<Para>
888-
They can have rule qualifications.
889-
</Para>
890-
</ListItem>
887+
<Para>
888+
They can have rule qualifications.
889+
</Para>
890+
</ListItem>
891891
</ItemizedList>
892892

893893
Second, they don't modify the query tree in place. Instead they
@@ -1875,14 +1875,15 @@ GRANT SELECT ON phone_number TO secretary;
18751875
</Para>
18761876

18771877
<Para>
1878-
For the things that can be implemented by both,
1879-
itdepends on the usage of the database, which is the best.
1878+
For the things that can be implemented by both, which is best
1879+
depends on the usage of the database.
18801880
A trigger is fired for any affected row once. A rule manipulates
1881-
the querytreeor generates an additionalone. So if many
1881+
the query or generates an additionalquery. So if many
18821882
rows are affected in one statement, a rule issuing one extra
1883-
commandwould usually do a better job than a trigger that is
1883+
commandis likely to be faster than a trigger that is
18841884
called for every single row and must execute its operations
1885-
many times.
1885+
many times. However, the trigger approach is conceptually far
1886+
simpler than the rule approach, and is easier for novices to get right.
18861887
</Para>
18871888

18881889
<Para>

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp