Обсуждение: Correct comment wording in extension.c
I think I've found a small issue.
When studying the following comment：
' The control file will be search on Extension_control_path paths if
control->control_dir is NULL, otherwise it will use the value of control_dir
to read and parse the .control file, so it assume that the control_dir is a
valid path for the control file being parsed.' in the extension.c
I think there are some minor errors in this sentence.
I believe:
'will be searched' is better than 'will be search'.
'it assumes' is better than 'it assume'.
Вложения
On Wed, Jan 7, 2026 at 1:13 PM albert tan <alterttan1223@gmail.com> wrote: > I believe: > 'will be searched' is better than 'will be search'. > 'it assumes' is better than 'it assume'. Those are indeed grammatical errors. From a quick eyeball scan, this file has other wording issues: /* * Ignore already-found names. They are not reachable by the * path search, so don't shown them. */ "show" /* * The directory parameter can be omitted, absolute, or relative to the * installation's base directory, which can be the sharedir or a custom * path that it was set extension_control_path. It depends where the * .control file was found. */ I imagine this means "or a custom path that was set via extension_control_path". /* * Return a list of directories declared on extension_control_path GUC. */ I would guess this normally phrased something like "Return the list of directories in extension_control_path". -- John Naylor Amazon Web Services
>> I believe:
>> 'will be searched' is better than 'will be search'.
>> 'it assumes' is better than 'it assume'.
>
>Those are indeed grammatical errors. From a quick eyeball scan, this
>file has other wording issues:
>
>/*
> * Ignore already-found names. They are not reachable by the
> * path search, so don't shown them.
> */
>
>"show"
>
>/*
> * The directory parameter can be omitted, absolute, or relative to the
> * installation's base directory, which can be the sharedir or a custom
> * path that it was set extension_control_path. It depends where the
> * .control file was found.
> */
>
>I imagine this means "or a custom path that was set via extension_control_path".
>
>/*
> * Return a list of directories declared on extension_control_path GUC.
> */
>I would guess this normally phrased something like "Return the list of
>directories in extension_control_path".
Hi Join,
Thanks for pointing out extra issues. I have addressed them in v2.
On Wed, Jan 7, 2026 at 1:13 PM albert tan <alterttan1223@gmail.com> wrote:
> I believe:
> 'will be searched' is better than 'will be search'.
> 'it assumes' is better than 'it assume'.
Those are indeed grammatical errors. From a quick eyeball scan, this
file has other wording issues:
/*
* Ignore already-found names. They are not reachable by the
* path search, so don't shown them.
*/
"show"
/*
* The directory parameter can be omitted, absolute, or relative to the
* installation's base directory, which can be the sharedir or a custom
* path that it was set extension_control_path. It depends where the
* .control file was found.
*/
I imagine this means "or a custom path that was set via extension_control_path".
/*
* Return a list of directories declared on extension_control_path GUC.
*/
I would guess this normally phrased something like "Return the list of
directories in extension_control_path".
--
John Naylor
Amazon Web Services
Вложения
>On Wed, Jan 7, 2026 at 1:13 PM albert tan <alterttan1223@gmail.com> wrote:
>Hi Join,
>Thanks for pointing out extra issues. I have addressed them in v2.
Hi Albert, John,
In addition to the previous findings, I went through src/backend/commands/extension.c again and identified other spots that need adjustment for better clarity and grammar.
In the header for find_in_paths:
/*
* Work in a very similar way with find_in_path but it receives an already
* parsed List of paths to search the basename and it do not support macro
* replacement or custom error messages (for simplicity).
*
* By "already parsed List of paths" this function expected that paths already
* have all macros replaced.
*/
This should be corrected to:
"Works in a very similar way to find_in_path, but it receives an already parsed List of paths to search the basename, and it does not support macro replacement or custom error messages (for simplicity). By 'already parsed List of paths' this function expects that the paths already have all macros replaced."
I hope this helps in making the file more consistent.
Best regards,
Yuan Li(carol)
>On Wed, Jan 7, 2026 at 1:13 PM albert tan <alterttan1223@gmail.com> wrote:
>Hi Join,
>Thanks for pointing out extra issues. I have addressed them in v2.
Hi Albert, John,
In addition to the previous findings, I went through src/backend/commands/extension.c again and identified other spots that need adjustment for better clarity and grammar.
In the header for find_in_paths:
/*
* Work in a very similar way with find_in_path but it receives an already
* parsed List of paths to search the basename and it do not support macro
* replacement or custom error messages (for simplicity).
*
* By "already parsed List of paths" this function expected that paths already
* have all macros replaced.
*/
This should be corrected to:
"Works in a very similar way to find_in_path, but it receives an already parsed List of paths to search the basename, and it does not support macro replacement or custom error messages (for simplicity). By 'already parsed List of paths' this function expects that the paths already have all macros replaced."
I hope this helps in making the file more consistent.
Best regards,
Yuan Li(carol)