@@ -1083,10 +1083,10 @@ SELECT x, g FROM tab, LATERAL generate_series(1,5) AS g;
10831083</programlisting>
10841084 It would be exactly the same, except that in this specific example,
10851085 the planner could choose to put <structname>g</structname> on the outside of the
1086- nestloop join, since <structname>g</structname> has no actual lateral dependency
1086+ nested-loop join, since <structname>g</structname> has no actual lateral dependency
10871087 on <structname>tab</structname>. That would result in a different output row
10881088 order. Set-returning functions in the select list are always evaluated
1089- as though they are on the inside of a nestloop join with the rest of
1089+ as though they are on the inside of a nested-loop join with the rest of
10901090 the <literal>FROM</literal> clause, so that the function(s) are run to
10911091 completion before the next row from the <literal>FROM</literal> clause is
10921092 considered.
@@ -3441,14 +3441,14 @@ supportfn(internal) returns internal
34413441 </para>
34423442
34433443 <para>
3444- For target functions that return boolean, it is often useful to estimate
3445- the fraction of rows that will be selected by a WHERE clause using that
3444+ For target functions that return <type> boolean</type> , it is often useful to estimate
3445+ the fraction of rows that will be selected by a <literal> WHERE</literal> clause using that
34463446 function. This can be done by a support function that implements
34473447 the <literal>SupportRequestSelectivity</literal> request type.
34483448 </para>
34493449
34503450 <para>
3451- If the target function's runtime is highly dependent on its inputs,
3451+ If the target function's run time is highly dependent on its inputs,
34523452 it may be useful to provide a non-constant cost estimate for it.
34533453 This can be done by a support function that implements
34543454 the <literal>SupportRequestCost</literal> request type.
@@ -3462,15 +3462,15 @@ supportfn(internal) returns internal
34623462 </para>
34633463
34643464 <para>
3465- For target functions that return boolean, it may be possible to
3466- convert a function call appearing in WHERE into an indexable operator
3465+ For target functions that return <type> boolean</type> , it may be possible to
3466+ convert a function call appearing in <literal> WHERE</literal> into an indexable operator
34673467 clause or clauses. The converted clauses might be exactly equivalent
34683468 to the function's condition, or they could be somewhat weaker (that is,
34693469 they might accept some values that the function condition does not).
34703470 In the latter case the index condition is said to
34713471 be <firstterm>lossy</firstterm>; it can still be used to scan an index,
34723472 but the function call will have to be executed for each row returned by
3473- the index to see if it really passes the WHERE condition or not.
3473+ the index to see if it really passes the <literal> WHERE</literal> condition or not.
34743474 To create such conditions, the support function must implement
34753475 the <literal>SupportRequestIndexCondition</literal> request type.
34763476 </para>
0 commit comments