func.sgmlのPostgreSQL 17.0対応です。 #3131

tatsuo-ishii · 2024-10-13T07:23:52Z

No description provided.

noborus

とりあえず先に機械的にチェックした項目だけ送ります。

noborus · 2024-10-27T08:35:32Z

doc/src/sgml/func2.sgml

-《機械翻訳》与えられた時間帯<emphasis>と</emphasis>時間帯を新しい時間帯に変換します。
-日付が与えられていないので、セッションの<varname>TimeZone</varname>値に現在有効なUTCオフセットを使用します。
+与えられた時刻<emphasis>with</emphasis> time zoneを新しい時間帯に変換します。
+日付が与えられていないので、現在の有効なUTCオフセットを目的の時間帯のために使用します。


マッチ度の文は似た別の箇所の文を引っ張ってきてしまってます。
セッションの<varname>TimeZone</varname>値に現在有効なUTCオフセットを使用します。のほうが正解かと。

ありがとうございます。いただきます。

noborus · 2024-10-27T08:40:11Z

doc/src/sgml/func.sgml

+<literal>ON ERROR</literal>句は、<replaceable>path_expression</replaceable>の評価中にエラーが発生した場合の動作を指定します。
+<literal>ERROR</literal>を指定すると、適切なメッセージとともにエラーを引き起こします。
+他のオプションには<type>boolean</type>値である<literal>FALSE</literal>または<literal>TRUE</literal>、あるいは実際にはSQL NULLである<literal>UNKNOWN</literal>の値を返すものがあります。
+<literal>ON_ERROR</literal>句が指定されていない場合のデフォルトでは、<type>boolean</type>値の<literal>FALSE</literal>を返します。


原文は <literal>ON ERROR</literal> ですね（アンダーバーが入らない）。

修正します。

noborus · 2024-10-27T08:40:24Z

doc/src/sgml/func.sgml

-<literal>ON EMPTY</literal>または<literal>ON ERROR</literal>が指定されていない場合のデフォルトは、SQL null値を返すことです。
+<literal>ON EMPTY</literal>と<literal>ON ERROR</literal>の両方で、<literal>ERROR</literal>を指定すると、適切なエラーとともにメッセージがスローされます。
+他のオプションにはSQL NULL、空の配列（<literal>EMPTY <optional>ARRAY</optional></literal>）、空のオブジェクト（<literal>EMPTY OBJECT</literal>）、jsonbまたは<literal>RETURNING</literal>で指定されたタイプに強制できるユーザ指定の式（<literal>DEFAULT</literal> <replaceable>expression</replaceable>）があります。
+<literal>ON_ERROR</literal>句が指定されていない場合のデフォルトでは、SQL NULL値を返します。


<literal>ON EMPTY</literal>またはが抜けています。
また原文は <literal>ON ERROR</literal> ですね（アンダーバーが入らない）。

修正します。

noborus · 2024-10-27T08:40:34Z

doc/src/sgml/func3.sgml

+<literal>ON ERROR</literal>句は、<replaceable>path_expression</replaceable>の評価中にエラーが発生した場合の動作を指定します。
+<literal>ERROR</literal>を指定すると、適切なメッセージとともにエラーを引き起こします。
+他のオプションには<type>boolean</type>値である<literal>FALSE</literal>または<literal>TRUE</literal>、あるいは実際にはSQL NULLである<literal>UNKNOWN</literal>の値を返すものがあります。
+<literal>ON_ERROR</literal>句が指定されていない場合のデフォルトでは、<type>boolean</type>値の<literal>FALSE</literal>を返します。


原文は <literal>ON ERROR</literal> ですね。

修正します。

noborus · 2024-10-27T08:40:44Z

doc/src/sgml/func3.sgml

-<literal>ON EMPTY</literal>または<literal>ON ERROR</literal>が指定されていない場合のデフォルトは、SQL null値を返すことです。
+<literal>ON EMPTY</literal>と<literal>ON ERROR</literal>の両方で、<literal>ERROR</literal>を指定すると、適切なエラーとともにメッセージがスローされます。
+他のオプションにはSQL NULL、空の配列（<literal>EMPTY <optional>ARRAY</optional></literal>）、空のオブジェクト（<literal>EMPTY OBJECT</literal>）、jsonbまたは<literal>RETURNING</literal>で指定されたタイプに強制できるユーザ指定の式（<literal>DEFAULT</literal> <replaceable>expression</replaceable>）があります。
+<literal>ON_ERROR</literal>句が指定されていない場合のデフォルトでは、SQL NULL値を返します。


原文は <literal>ON ERROR</literal> ですね。

修正します。

noborus · 2024-10-27T08:43:01Z

doc/src/sgml/func.sgml

-ラッパー値が存在する場合にのみマルチプルを適用するには、<literal>WITH CONDITIONALラッパー</literal>を指定します。
-<literal>WITHOUTマルチプル</literal>が指定されている場合、結果内のエラー値の取得はラッパーとして扱われます。
+パス式が複数の結果を返す場合、それらの値を適切なJSON文字列にするために、<literal>WITH WRAPPER</literal>句を使用してこれらの値をラップする必要があります。
+なぜなら、デフォルトの動作は、<literal>WITHOUT_WRAPPER</literal>が指定されているかのようにラップしないからです。


原文は<literal>WITHOUT WRAPPER</literal>ですね。

修正します。

noborus · 2024-10-27T08:43:32Z

doc/src/sgml/func.sgml

-<literal>WITHOUTマルチプル</literal>が指定されている場合、結果内のエラー値の取得はラッパーとして扱われます。
+パス式が複数の結果を返す場合、それらの値を適切なJSON文字列にするために、<literal>WITH WRAPPER</literal>句を使用してこれらの値をラップする必要があります。
+なぜなら、デフォルトの動作は、<literal>WITHOUT_WRAPPER</literal>が指定されているかのようにラップしないからです。
+<literal>WITH_WRAPPER</literal>句は、デフォルトでは<literal>WITH UNCONDITIONAL WRAPPER</literal>を意味すると解釈されます。これは、単一の結果値であってもラップされることを意味します。


原文は<literal>WITH WRAPPER</literal>

修正します。

noborus · 2024-10-27T08:44:18Z

doc/src/sgml/func.sgml

+パス式が複数の結果を返す場合、それらの値を適切なJSON文字列にするために、<literal>WITH WRAPPER</literal>句を使用してこれらの値をラップする必要があります。
+なぜなら、デフォルトの動作は、<literal>WITHOUT_WRAPPER</literal>が指定されているかのようにラップしないからです。
+<literal>WITH_WRAPPER</literal>句は、デフォルトでは<literal>WITH UNCONDITIONAL WRAPPER</literal>を意味すると解釈されます。これは、単一の結果値であってもラップされることを意味します。
+複数の値が存在する場合にのみラッパーを適用するには、<literal>WITH CONDITIONAL_WRAPPER</literal>を指定します。


原文は<literal>WITH CONDITIONAL WRAPPER</literal>

修正します。

noborus · 2024-10-27T08:44:47Z

doc/src/sgml/func.sgml

+なぜなら、デフォルトの動作は、<literal>WITHOUT_WRAPPER</literal>が指定されているかのようにラップしないからです。
+<literal>WITH_WRAPPER</literal>句は、デフォルトでは<literal>WITH UNCONDITIONAL WRAPPER</literal>を意味すると解釈されます。これは、単一の結果値であってもラップされることを意味します。
+複数の値が存在する場合にのみラッパーを適用するには、<literal>WITH CONDITIONAL_WRAPPER</literal>を指定します。
+<literal>WITHOUT_WRAPPER</literal>が指定されていて、結果に複数の値が含まれると、エラーとして扱われます。


原文は<literal>WITHOUT_WRAPPER</literal>

修正します。

小泉さんの指摘ですが、17.0で直してしまうと、16.0で修正した時に上書きされそうなので対応していません。

tatsuo-ishii

レビューありがとうございます。

tatsuo-ishii · 2024-11-03T10:10:39Z

doc/src/sgml/func2.sgml

-《機械翻訳》与えられた時間帯<emphasis>と</emphasis>時間帯を新しい時間帯に変換します。
-日付が与えられていないので、セッションの<varname>TimeZone</varname>値に現在有効なUTCオフセットを使用します。
+与えられた時刻<emphasis>with</emphasis> time zoneを新しい時間帯に変換します。
+日付が与えられていないので、現在の有効なUTCオフセットを目的の時間帯のために使用します。


ありがとうございます。いただきます。

tatsuo-ishii · 2024-11-03T10:12:40Z

doc/src/sgml/func3.sgml

+<literal>ON ERROR</literal>句は、<replaceable>path_expression</replaceable>の評価中にエラーが発生した場合の動作を指定します。
+<literal>ERROR</literal>を指定すると、適切なメッセージとともにエラーを引き起こします。
+他のオプションには<type>boolean</type>値である<literal>FALSE</literal>または<literal>TRUE</literal>、あるいは実際にはSQL NULLである<literal>UNKNOWN</literal>の値を返すものがあります。
+<literal>ON_ERROR</literal>句が指定されていない場合のデフォルトでは、<type>boolean</type>値の<literal>FALSE</literal>を返します。


修正します。

tatsuo-ishii · 2024-11-03T10:13:05Z

doc/src/sgml/func3.sgml

-<literal>ON EMPTY</literal>または<literal>ON ERROR</literal>が指定されていない場合のデフォルトは、SQL null値を返すことです。
+<literal>ON EMPTY</literal>と<literal>ON ERROR</literal>の両方で、<literal>ERROR</literal>を指定すると、適切なエラーとともにメッセージがスローされます。
+他のオプションにはSQL NULL、空の配列（<literal>EMPTY <optional>ARRAY</optional></literal>）、空のオブジェクト（<literal>EMPTY OBJECT</literal>）、jsonbまたは<literal>RETURNING</literal>で指定されたタイプに強制できるユーザ指定の式（<literal>DEFAULT</literal> <replaceable>expression</replaceable>）があります。
+<literal>ON_ERROR</literal>句が指定されていない場合のデフォルトでは、SQL NULL値を返します。


修正します。

tatsuo-ishii · 2024-11-03T10:14:54Z

doc/src/sgml/func.sgml

+<literal>ON ERROR</literal>句は、<replaceable>path_expression</replaceable>の評価中にエラーが発生した場合の動作を指定します。
+<literal>ERROR</literal>を指定すると、適切なメッセージとともにエラーを引き起こします。
+他のオプションには<type>boolean</type>値である<literal>FALSE</literal>または<literal>TRUE</literal>、あるいは実際にはSQL NULLである<literal>UNKNOWN</literal>の値を返すものがあります。
+<literal>ON_ERROR</literal>句が指定されていない場合のデフォルトでは、<type>boolean</type>値の<literal>FALSE</literal>を返します。


修正します。

tatsuo-ishii · 2024-11-03T10:16:08Z

doc/src/sgml/func.sgml

-<literal>ON EMPTY</literal>または<literal>ON ERROR</literal>が指定されていない場合のデフォルトは、SQL null値を返すことです。
+<literal>ON EMPTY</literal>と<literal>ON ERROR</literal>の両方で、<literal>ERROR</literal>を指定すると、適切なエラーとともにメッセージがスローされます。
+他のオプションにはSQL NULL、空の配列（<literal>EMPTY <optional>ARRAY</optional></literal>）、空のオブジェクト（<literal>EMPTY OBJECT</literal>）、jsonbまたは<literal>RETURNING</literal>で指定されたタイプに強制できるユーザ指定の式（<literal>DEFAULT</literal> <replaceable>expression</replaceable>）があります。
+<literal>ON_ERROR</literal>句が指定されていない場合のデフォルトでは、SQL NULL値を返します。


修正します。

tatsuo-ishii · 2024-11-03T10:17:40Z

doc/src/sgml/func.sgml

-ラッパー値が存在する場合にのみマルチプルを適用するには、<literal>WITH CONDITIONALラッパー</literal>を指定します。
-<literal>WITHOUTマルチプル</literal>が指定されている場合、結果内のエラー値の取得はラッパーとして扱われます。
+パス式が複数の結果を返す場合、それらの値を適切なJSON文字列にするために、<literal>WITH WRAPPER</literal>句を使用してこれらの値をラップする必要があります。
+なぜなら、デフォルトの動作は、<literal>WITHOUT_WRAPPER</literal>が指定されているかのようにラップしないからです。


修正します。

tatsuo-ishii · 2024-11-03T10:18:30Z

doc/src/sgml/func.sgml

-<literal>WITHOUTマルチプル</literal>が指定されている場合、結果内のエラー値の取得はラッパーとして扱われます。
+パス式が複数の結果を返す場合、それらの値を適切なJSON文字列にするために、<literal>WITH WRAPPER</literal>句を使用してこれらの値をラップする必要があります。
+なぜなら、デフォルトの動作は、<literal>WITHOUT_WRAPPER</literal>が指定されているかのようにラップしないからです。
+<literal>WITH_WRAPPER</literal>句は、デフォルトでは<literal>WITH UNCONDITIONAL WRAPPER</literal>を意味すると解釈されます。これは、単一の結果値であってもラップされることを意味します。


修正します。

tatsuo-ishii · 2024-11-03T10:18:56Z

doc/src/sgml/func.sgml

+パス式が複数の結果を返す場合、それらの値を適切なJSON文字列にするために、<literal>WITH WRAPPER</literal>句を使用してこれらの値をラップする必要があります。
+なぜなら、デフォルトの動作は、<literal>WITHOUT_WRAPPER</literal>が指定されているかのようにラップしないからです。
+<literal>WITH_WRAPPER</literal>句は、デフォルトでは<literal>WITH UNCONDITIONAL WRAPPER</literal>を意味すると解釈されます。これは、単一の結果値であってもラップされることを意味します。
+複数の値が存在する場合にのみラッパーを適用するには、<literal>WITH CONDITIONAL_WRAPPER</literal>を指定します。


修正します。

tatsuo-ishii · 2024-11-03T10:19:20Z

doc/src/sgml/func.sgml

+なぜなら、デフォルトの動作は、<literal>WITHOUT_WRAPPER</literal>が指定されているかのようにラップしないからです。
+<literal>WITH_WRAPPER</literal>句は、デフォルトでは<literal>WITH UNCONDITIONAL WRAPPER</literal>を意味すると解釈されます。これは、単一の結果値であってもラップされることを意味します。
+複数の値が存在する場合にのみラッパーを適用するには、<literal>WITH CONDITIONAL_WRAPPER</literal>を指定します。
+<literal>WITHOUT_WRAPPER</literal>が指定されていて、結果に複数の値が含まれると、エラーとして扱われます。


修正します。

KenichiroTanaka

時間がかかっておりすみません。func3までチェックしたのでここで一度区切ります。

KenichiroTanaka · 2024-11-04T23:59:37Z

doc/src/sgml/func2.sgml

@@ -3705,13 +3713,9 @@ SELECT EXTRACT(MINUTES FROM INTERVAL '80 minutes');
     For other fields, NULL is returned.  <productname>PostgreSQL</productname>
     versions before 9.6 returned zero for all cases of infinite input.
 -->
-《マッチ度[61.785216]》入力値が+/-無限大の場合、<function>extract</function>は単調増加するフィールド（<literal>epoch</literal>、<literal>julian</literal>、<literal>year</literal>、<literal>isoyear</literal>、<literal>decade</literal>、<literal>century</literal>、<literal>millennium</literal>）に対し、+/-無限大を返します。
+入力値が+/-無限大の場合、<function>extract</function>は単調増加するフィールド（<type>timestamp</type>入力については<literal>epoch</literal>、<literal>julian</literal>、<literal>year</literal>、<literal>isoyear</literal>、<literal>decade</literal>、<literal>century</literal>、<literal>millennium</literal>、<type>interval</type>入力については<literal>epoch</literal>、<literal>hour</literal>、<literal>day</literal>、<literal>year</literal>、<literal>decade</literal>、<literal>century</literal>、<literal>millennium</literal>）に対し、+/-無限大を返します。


timestamp入力については〜の箇所の文の句切れはmillennium、intervalの間なのですが、それ以前も「、」で区切られているため、判別がつきにくいように思いました。原文の「；」をどのように表現するかなのですが、文の数を変えないようにするのであれば、

<type>timestamp</type>入力については<literal>epoch</literal>、<literal>julian</literal>、 <literal>year</literal>、<literal>isoyear</literal>、<literal>decade</literal>、<literal>century</literal>、<literal>millennium</literal>に、<type>interval</type>入力については<literal>epoch</literal>、 <literal>hour</literal>、<literal>day</literal>、<literal>year</literal>、<literal>decade</literal>、 <literal>century</literal>、<literal>millennium</literal>）

などとするのはどうでしょうか。

ありがとうございます。いただきます。

KenichiroTanaka · 2024-11-05T00:18:42Z

doc/src/sgml/func3.sgml

@@ -615,7 +615,7 @@ JSON値が配列でなければエラーが生じます。
        <link linkend="functions-sqljson-check-expressions">predicate check
        expressions</link>, since those always return a value.)
 -->
-《機械翻訳》JSONパスは指定されたJSON値に対して何らかの項目を返しますか?（これはSQL標準のJSONパス式でのみ有用であり、<link linkend="functions-sqljson-check-expressions">述語チェック式</link>では値を返しません。）
+JSONパスは指定されたJSON値に対して何らかの項目を返すか?（これはSQL標準のJSONパス式でのみ有用であり、<link linkend="functions-sqljson-check-expressions">述語チェック式</link>では値を返しません。）


機械翻訳の箇所ですが
since those always return a value
の訳が誤っているように思います。

これはSQL標準のJSONパス式でのみ有用であり、<link linkend="functions-sqljson-check-expressions">述語チェック式</link>では有効ではありません。このため、これらは常に値を返します。

などの訳になるのかなと思います。

機械翻訳が誤っているのはそのとおりだと思います。ただ、since...は「...だから」と理由を述べていると思うので、ご提案の訳では違うと思います。以下のようにしました。
（これはSQL標準のJSONパス式でのみ有用であり、<link linkend="functions-sqljson-check-expressions">述語チェック式</link>では有効ではありません。述語チェック式は常に値を返すからです。）

KenichiroTanaka · 2024-11-07T22:01:14Z

doc/src/sgml/func3.sgml

@@ -2517,10 +2495,8 @@ JSON配列インデックスは0スタートであることに注意してくだ
   <literal>WHERE</literal> clause in SQL. A filter expression begins with
   a question mark and provides a condition in parentheses:
 -->
-《マッチ度[79.638009]》パスを定義する際にはSQLの<literal>WHERE</literal>節のように働く一つ以上の<firstterm>フィルター式</firstterm>が利用できます。
+パスには、SQLの<literal>WHERE</literal>節のように働く<firstterm>フィルター式</firstterm>を含めることもできます。


元からのところですが、他の箇所同様、clauseは「節」ではなく「句」が良いかと思います。

たしかに。修正します。

KenichiroTanaka · 2024-11-08T13:01:08Z

doc/src/sgml/func3.sgml

+これらの各関数は、<replaceable>path_expression</replaceable>（SQL/JSONパス問い合わせ）を<replaceable>context_item</replaceable>（文書）に適用します。
+<replaceable>path_expression</replaceable>の内容の詳細については、<xref linkend="functions-sqljson-path"/>を参照してください。
+<replaceable>path_expression</replaceable>はリファレンス変数にすることもできます。その値は、各関数でサポートされている<literal>PASSING</literal>句でそれぞれの名前で指定されます。
+<replaceable>context_item</replaceable>には、<type>jsonb</type>の値、または<type>文字の並び</type>にキャストできるjsonbを指定できます。


機械翻訳の場所ですが、typeタグの位置がbugっているように思います。

「または<type>文字の並び</type>にキャストできるjsonbを指定できます。」

↓

「または文字の並びにキャストできる<type>jsonb</type>を指定できます。」

かと思います。

見逃してました。

KenichiroTanaka · 2024-11-08T13:17:20Z

doc/src/sgml/func3.sgml

@@ -4256,10 +4203,10 @@ ERROR:  jsonpath array subscript is out of bounds
        cannot be specified when <literal>WITH WRAPPER</literal> is also
        specified.
 -->
-《機械翻訳》結果がスカラ文字列、デフォルトの場合、戻り値は引用符で囲まれ、有効なJSON値になります。
+結果がスカラ文字列、デフォルトの場合、戻り値は引用符で囲まれ、有効なJSON値になります。


機械翻訳の箇所ですが
「結果がスカラ文字列、デフォルトの場合、戻り値は引用符で囲まれ、有効なJSON値になります。」
の「デフォルトの場合」が少しわかりづらく感じました。
「結果がスカラ文字列の場合、デフォルトでは戻り値は引用符で囲まれ、有効なJSON値になります。」

とするのはどうでしょうか

良いですね。いただきます。

KenichiroTanaka · 2024-11-08T13:18:34Z

doc/src/sgml/func3.sgml

-《機械翻訳》<literal>ON EMPTY</literal>句は、<replaceable>path_expression</replaceable>を評価すると空のセットが生成される場合の動作を指定します。
-<literal>ON ERROR</literal>句は、<replaceable>path_expression</replaceable>を評価するとき、結果値を<literal>RETURNING</literal>タイプに強制するとき、または<replaceable>path_expression</replaceable>評価で空のセットが返される場合に<literal>ON EMPTY</literal>式を評価するときにエラーが発生する場合の動作を指定します。
+<literal>ON EMPTY</literal>句は、<replaceable>path_expression</replaceable>を評価した結果空の集合が生成される場合の動作を指定します。
+<literal>ON ERROR</literal>句は、<replaceable>path_expression</replaceable>を評価した祭、結果値を<literal>RETURNING</literal>型に強制した祭、または<replaceable>path_expression</replaceable>評価で空の集合が返され<literal>ON EMPTY</literal>式を評価した際にエラーが発生する場合の動作を指定します。


祭→際かと思います（2箇所）

修正します。

KenichiroTanaka · 2024-11-08T13:30:39Z

doc/src/sgml/func3.sgml

@@ -4381,7 +4324,7 @@ DETAIL:  Missing "]" after array dimensions.
        <function>JSON_QUERY</function>, except the set of values returned in
        lieu of throwing an error is different.
 -->
-《機械翻訳》<literal>ON ERROR</literal>句と<literal>ON EMPTY</literal>句のセマンティクスは、<function>JSON_QUERY</function>の説明で説明したものと似ていますが、エラーをスローする代わりに返される値のセットが異なります。
+<literal>ON ERROR</literal>句と<literal>ON EMPTY</literal>句のセマンティクスは、<function>JSON_QUERY</function>の説明で説明したものと似ていますが、エラーを生起する代わりに返される値の集合が異なります。


「エラー生起する」という表現は日本語としては正しいですが、他では使われていないようです。
「エラーを発生する代わりに」
などの表現の方が見慣れているのですがどちらが良いでしょうか。

特にこだわりはないので、「エラーを発生する代わりに」に修正します。(以下同様)

KenichiroTanaka · 2024-11-08T14:56:47Z

doc/src/sgml/func3.sgml

@@ -4683,7 +4624,7 @@ where <replaceable class="parameter">json_table_column</replaceable> is:
     coercing the SQL/JSON value to the specified type, respectively.  The
     default for both is to return a <literal>NULL</literal> value.
 -->
-《機械翻訳》オプションで、<literal>ON EMPTY</literal>と<literal>ON ERROR</literal>句を使用して、JSONパス評価の結果が空の場合にエラーをスローするか、JSONパス評価中にエラーが発生した場合に指定された値をスローするかを指定できます。
+オプションで、<literal>ON EMPTY</literal>と<literal>ON ERROR</literal>句を使用して、JSONパス評価の結果が空の場合と、JSONパスの評価中あるいはSQL/JSON値を指定された型に強制変換したときにエラーが発生した場合に対して、エラーを生起するか、指定された値を返すかをそれぞれ指定できます。


生起に関して上の指摘と同じです。

KenichiroTanaka · 2024-11-08T14:59:06Z

doc/src/sgml/func3.sgml

@@ -4739,7 +4680,7 @@ where <replaceable class="parameter">json_table_column</replaceable> is:
     type.  The default is to return a boolean value
     <literal>FALSE</literal>.
 -->
-《機械翻訳》オプションで<literal>ON ERROR</literal>を使用して、JSONパス評価中にエラーが発生した場合、またはSQL/JSON値を指定された型に強制変換した場合に、エラーをスローするか、指定された値を返すかを指定できます。
+オプションで<literal>ON ERROR</literal>を使用して、JSONパス評価中にエラーが発生した場合、またはSQL/JSON値を指定された型に強制変換した場合に、エラーを生起するか、指定された値を返すかを指定できます。


生起に関して、前の指摘と同様です。

KenichiroTanaka · 2024-11-08T15:01:51Z

doc/src/sgml/func3.sgml

-《機械翻訳》オプションの<literal>ON ERROR</literal>は、最上位の<replaceable>path_expression</replaceable>を評価する際のエラー処理方法を指定するために使用できます。
-エラーをスローする場合は<literal>ERROR</literal>を使用し、空のテーブル、つまり0行を含むテーブルを返す場合は<literal>EMPTY</literal>を使用します。
+オプションの<literal>ON ERROR</literal>は、最上位の<replaceable>path_expression</replaceable>を評価する際のエラー処理方法を指定するために使用できます。
+エラーを生起する場合は<literal>ERROR</literal>を使用し、空のテーブル、つまり0行を含むテーブルを返す場合は<literal>EMPTY</literal>を使用します。


生起に関して、先の指摘と同様です。

KenichiroTanaka

大変お待たせしました。
あといくつか気づいたところがありましたので見ていただいてもいいでしょうか。

KenichiroTanaka · 2024-11-11T23:03:51Z

doc/src/sgml/func4.sgml

@@ -3265,7 +3265,7 @@ SELECT pg_type_is_visible('myschema.widget'::regtype);
        not a valid type OID.  If there's a chain of domain dependencies,
        it will recurse until finding the base type.
 -->
-《機械翻訳》ドメインの型のOIDで識別される基本型のOIDを返します。
+OIDで識別されるドメイン型の基本型のOIDを返します。
 引数がドメイン以外の型のOIDの場合、引数をそのまま返します。
 引数が有効な型OIDでない場合、基本型が見つかるまで再帰します。


機械翻訳の箇所ですが、
「Returns NULL if the argument is not a valid type OID. 」
の訳が下の行にひきづられているようです。
「引数が有効な型OIDでない場合、NULLを返します。」
などでしょうか。

ありがとうございます。そのままいただきます。
その他にも周辺にいくつか誤りがあったので修正しました。

KenichiroTanaka · 2024-11-11T23:16:00Z

doc/src/sgml/func4.sgml

@@ -6161,10 +6167,10 @@ OIDとそれを含むシステム型で指定されるデータベース共有
        the relevant range of WAL records; in such cases,
        <literal>relblocknumber</literal> will be zero.
 -->
-《機械翻訳》TLIで識別される単一のWAL要約ファイルの内容に関する情報を返します。
+TLIで識別され、開始LSNと終了LSNの範囲の単一のWAL要約ファイルの内容に関する情報を返します。
 開始LSNと終了LSNを指定します。


この１行は機会翻訳の紛れでしょうか。不要のように思います。

はい、削除します。

KenichiroTanaka · 2024-11-12T12:38:34Z

doc/src/sgml/func4.sgml

+WAL要約処理の進捗に関する情報を返します。
+インスタンスが開始されてからWAL要約処理が一度も実行されていない場合、<literal>summarized_tli</literal>と<literal>summarized_lsn</literal>はそれぞれ<literal>0</literal>と<literal>0/0</literal>になります。それ以外の場合は、ディスクに書き込まれた最後のWAL要約ファイルのTLIと終了LSNになります。
+WAL要約処理が現在動作している場合、<literal>pending_lsn</literal>は消費した最後のレコードの終了LSNで、必ず<literal>summarized_lsn</literal>の以上になり、WAL要約処理が動作していない場合、<literal>summarized_lsn</literal>と等しくなります。
+<literal>summarizer_pid</literal>はWAL要約処理が動作している場合はプロセスのPIDです。動作していない場合はnullのPIDです。


機械翻訳の箇所ですが、
「動作していない場合はnullのPIDです」
は
「動作していない場合のPIDはnullです」
わかりやすいかと思います。

そうですね。あと、"null"は原文通りNULLにすべきと思うので、NULLにします。

KenichiroTanaka · 2024-11-12T12:49:21Z

doc/src/sgml/func4.sgml

+スロットは後方には動きませんし、現在の挿入位置を超えて進むこともありません。
+スロットの名前と前に進んだ実際の位置を返します。
+前に進んだ場合は更新されたスロットに関する情報がこの後のチェックポイントで書き出されます。
+クラッシュが発生すると、そのスロットは以前の位置に戻るかもしれません。
 指定されたスロットがロジカルフェイルオーバースロットである場合、関数は<link linkend="guc-synchronized-standby-slots"><varname>synchronized_standby_slots</varname></link>で指定された全ての物理的スロットがWAL受信を確認するまで結果しません。


ここも機械翻訳の箇所ですが
「WAL受信を確認するまで結果しません。」
は
「WAL受信を確認するまで結果を返しません。」
が良いかと思います。

はい、修正します。

tatsuo-ishii

レビューありがとうございます。

tatsuo-ishii · 2024-11-13T12:18:28Z

doc/src/sgml/func4.sgml

@@ -6161,10 +6167,10 @@ OIDとそれを含むシステム型で指定されるデータベース共有
        the relevant range of WAL records; in such cases,
        <literal>relblocknumber</literal> will be zero.
 -->
-《機械翻訳》TLIで識別される単一のWAL要約ファイルの内容に関する情報を返します。
+TLIで識別され、開始LSNと終了LSNの範囲の単一のWAL要約ファイルの内容に関する情報を返します。
 開始LSNと終了LSNを指定します。


はい、削除します。

tatsuo-ishii · 2024-11-13T12:20:49Z

doc/src/sgml/func4.sgml

+WAL要約処理の進捗に関する情報を返します。
+インスタンスが開始されてからWAL要約処理が一度も実行されていない場合、<literal>summarized_tli</literal>と<literal>summarized_lsn</literal>はそれぞれ<literal>0</literal>と<literal>0/0</literal>になります。それ以外の場合は、ディスクに書き込まれた最後のWAL要約ファイルのTLIと終了LSNになります。
+WAL要約処理が現在動作している場合、<literal>pending_lsn</literal>は消費した最後のレコードの終了LSNで、必ず<literal>summarized_lsn</literal>の以上になり、WAL要約処理が動作していない場合、<literal>summarized_lsn</literal>と等しくなります。
+<literal>summarizer_pid</literal>はWAL要約処理が動作している場合はプロセスのPIDです。動作していない場合はnullのPIDです。


そうですね。あと、"null"は原文通りNULLにすべきと思うので、NULLにします。

tatsuo-ishii · 2024-11-13T12:21:56Z

doc/src/sgml/func4.sgml

+スロットは後方には動きませんし、現在の挿入位置を超えて進むこともありません。
+スロットの名前と前に進んだ実際の位置を返します。
+前に進んだ場合は更新されたスロットに関する情報がこの後のチェックポイントで書き出されます。
+クラッシュが発生すると、そのスロットは以前の位置に戻るかもしれません。
 指定されたスロットがロジカルフェイルオーバースロットである場合、関数は<link linkend="guc-synchronized-standby-slots"><varname>synchronized_standby_slots</varname></link>で指定された全ての物理的スロットがWAL受信を確認するまで結果しません。


はい、修正します。

KenichiroTanaka

大きなファイルの対応ありがとうございました。
複数名のレビューが入りましたのでこの辺りでマージします。

func.sgmlのPostgreSQL 17.0対応です。

4b11246

github-actions bot added the レビュー待ち label Oct 13, 2024

クエリ → 問い合わせ

6045628

koizumistr mentioned this pull request Oct 20, 2024

fix typos in AT TIME ZONE #3140

Merged

noborus reviewed Oct 27, 2024

View reviewed changes

noborus added 指摘事項あり and removed レビュー待ち labels Oct 27, 2024

斉藤さんの指摘に対応しました。

5212380

小泉さんの指摘ですが、17.0で直してしまうと、16.0で修正した時に上書きされそうなので対応していません。

tatsuo-ishii commented Nov 3, 2024

View reviewed changes

github-actions bot added 再レビュー待ち and removed 指摘事項あり labels Nov 3, 2024

KenichiroTanaka reviewed Nov 8, 2024

View reviewed changes

田中さんの指摘に対応しました。

39f406a

KenichiroTanaka requested changes Nov 12, 2024

View reviewed changes

KenichiroTanaka added 指摘事項あり and removed 再レビュー待ち labels Nov 12, 2024

tatsuo-ishii commented Nov 13, 2024

View reviewed changes

田中さんのfunc4.sgmlへの指摘事項を修正しました。

bdb32b4

github-actions bot added 再レビュー待ち and removed 指摘事項あり labels Nov 13, 2024

KenichiroTanaka approved these changes Nov 13, 2024

View reviewed changes

KenichiroTanaka merged commit 8ed31b5 into pgsql-jp:doc_ja_17 Nov 13, 2024
2 checks passed

func.sgmlのPostgreSQL 17.0対応です。 #3131

func.sgmlのPostgreSQL 17.0対応です。 #3131

Conversation

tatsuo-ishii commented Oct 13, 2024

noborus left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tatsuo-ishii left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KenichiroTanaka left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tatsuo-ishii Nov 10, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KenichiroTanaka left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tatsuo-ishii left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KenichiroTanaka left a comment

Choose a reason for hiding this comment

tatsuo-ishii Nov 10, 2024 •

edited

Loading