Обсуждение: EXCLUDE COLLATE in CREATE/ALTER TABLE document
Hi hackers,
I hope this email finds you well.
I noticed that the CREATE/ALTER TABLE document does not mention that EXCLUDE can accept a collation. I created a documentation fix for this issue, and I have attached it to this email.
Please let me know if you have any questions or concerns.
Thanks,
Shihao
I hope this email finds you well.
I noticed that the CREATE/ALTER TABLE document does not mention that EXCLUDE can accept a collation. I created a documentation fix for this issue, and I have attached it to this email.
Please let me know if you have any questions or concerns.
Thanks,
Shihao
Вложения
shihao zhong <zhong950419@gmail.com> writes: > I noticed that the CREATE/ALTER TABLE document does not mention that > EXCLUDE can accept a collation. I created a documentation fix for this > issue, and I have attached it to this email. Hmm ... is this actually correct? I think that the collate option has to come before the opclass name etc, so you'd need to shove it into exclude_element to provide an accurate description of the syntax. regards, tom lane
On Tue, Oct 31, 2023 at 9:07 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
shihao zhong <zhong950419@gmail.com> writes:
> I noticed that the CREATE/ALTER TABLE document does not mention that
> EXCLUDE can accept a collation. I created a documentation fix for this
> issue, and I have attached it to this email.
> Hmm ... is this actually correct? I think that the collate
> option has to come before the opclass name etc, so you'd need
> to shove it into exclude_element to provide an accurate
> description of the syntax.
>
> regards, tom lane
Hi Tom,
Thank you for your feedback on my previous patch. I have fixed the issue and attached a new patch for your review. Could you please take a look for it if you have a sec? Thanks
Also, if I understand correctly, the changes to sql_help.c will be made by the committer, so I do not need to run create_help.pl in my patch. Can you please confirm?
Also, if I understand correctly, the changes to sql_help.c will be made by the committer, so I do not need to run create_help.pl in my patch. Can you please confirm?
I appreciate your help and time.
Thanks,
Shihao
Вложения
On Wed, Nov 1, 2023 at 10:30 AM shihao zhong <zhong950419@gmail.com> wrote: > > Thank you for your feedback on my previous patch. I have fixed the issue and attached a new patch for your review. Couldyou please take a look for it if you have a sec? Thanks > Your patch works fine. you can see it here: https://cirrus-ci.com/task/6481922939944960 in an ideal world, since the doc is already built, we can probably view it as a plain html file just click the ci test result. in src/sgml/ref/create_table.sgml: "Each exclude_element can optionally specify an operator class and/or ordering options; these are described fully under CREATE INDEX." You may need to update this sentence to reflect that exclude_element can also optionally specify collation.
Hi Jian,
Thanks for your comments, a new version is attached.
Thanks,
Shihao
On Fri, Nov 10, 2023 at 9:59 AM jian he <jian.universality@gmail.com> wrote:
On Wed, Nov 1, 2023 at 10:30 AM shihao zhong <zhong950419@gmail.com> wrote:
>
> Thank you for your feedback on my previous patch. I have fixed the issue and attached a new patch for your review. Could you please take a look for it if you have a sec? Thanks
>
Your patch works fine. you can see it here:
https://cirrus-ci.com/task/6481922939944960
in an ideal world, since the doc is already built, we can probably
view it as a plain html file just click the ci test result.
in src/sgml/ref/create_table.sgml:
"Each exclude_element can optionally specify an operator class and/or
ordering options; these are described fully under CREATE INDEX."
You may need to update this sentence to reflect that exclude_element
can also optionally specify collation.
Вложения
On Fri, Nov 17, 2023 at 4:55 AM shihao zhong <zhong950419@gmail.com> wrote: > > Hi Jian, > > Thanks for your comments, a new version is attached. > > Thanks, > Shihao > > On Fri, Nov 10, 2023 at 9:59 AM jian he <jian.universality@gmail.com> wrote: >> >> On Wed, Nov 1, 2023 at 10:30 AM shihao zhong <zhong950419@gmail.com> wrote: >> > >> > Thank you for your feedback on my previous patch. I have fixed the issue and attached a new patch for your review. Couldyou please take a look for it if you have a sec? Thanks >> > >> >> Your patch works fine. you can see it here: >> https://cirrus-ci.com/task/6481922939944960 >> in an ideal world, since the doc is already built, we can probably >> view it as a plain html file just click the ci test result. >> >> in src/sgml/ref/create_table.sgml: >> "Each exclude_element can optionally specify an operator class and/or >> ordering options; these are described fully under CREATE INDEX." >> >> You may need to update this sentence to reflect that exclude_element >> can also optionally specify collation. I have reviewed the changes and it looks fine. Thanks and Regards, Shubham Khanna.
shihao zhong wrote: > Thanks for your comments, a new version is attached. In this hunk: @@ -1097,8 +1097,8 @@ WITH ( MODULUS <replaceable class="parameter">numeric_literal</replaceable>, REM method <replaceable>index_method</replaceable>. The operators are required to be commutative. Each <replaceable class="parameter">exclude_element</replaceable> - can optionally specify an operator class and/or ordering options; - these are described fully under + can optionally specify any of the following: a collation, a + operator class, or ordering options; these are described fully under <xref linkend="sql-createindex"/>. </para> "a" should be "an" as it's followed by "operator class". Also the use of "and/or" in the previous version conveys the fact that operator class and ordering options are not mutually exclusive. But when using "any of the following" in the new text, doesn't it loose that meaning? In case it does, I would suggest the attached diff. Best regards, -- Daniel Vérité https://postgresql.verite.pro/ Twitter: @DanielVerite
Вложения
"Daniel Verite" <daniel@manitou-mail.org> writes: > Also the use of "and/or" in the previous version conveys the fact > that operator class and ordering options are not mutually > exclusive. But when using "any of the following" in the new text, > doesn't it loose that meaning? Yeah; and/or is perfectly fine here and doesn't need to be improved on. There's a bigger problem though, which is that these bits are *also* missing any reference to opclass parameters. I fixed that and pushed it. regards, tom lane