Horton

Thread

Commits

  1. Make OWNER TO subcommand mention consistent

  1. alter table doc fix

    Amit Langote <langote_amit_f8@lab.ntt.co.jp> — 2017-10-18T00:43:43Z

    Hi.

Noticed that a alter table sub-command's name in Description (where it's
OWNER) differs from that in synopsis (where it's OWNER TO).  Attached
patch to make them match, if the difference is unintentional.

Thanks,
Amit

  2. Re: alter table doc fix

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2017-10-18T11:37:22Z

    Amit Langote wrote:
> Hi.
> 
> Noticed that a alter table sub-command's name in Description (where it's
> OWNER) differs from that in synopsis (where it's OWNER TO).  Attached
> patch to make them match, if the difference is unintentional.

I agree -- pushed.

This paragraph

   <para>
    The actions for identity columns (<literal>ADD
    GENERATED</literal>, <literal>SET</literal> etc., <literal>DROP
    IDENTITY</literal>), as well as the actions
    <literal>TRIGGER</literal>, <literal>CLUSTER</literal>, <literal>OWNER</literal>,
    and <literal>TABLESPACE</literal> never recurse to descendant tables;
    that is, they always act as though <literal>ONLY</literal> were specified.
    Adding a constraint recurses only for <literal>CHECK</literal> constraints
    that are not marked <literal>NO INHERIT</literal>.
   </para>

is a bit annoying, though I think it'd be worse if we "fix" it to be
completely strict about the subcommands it refers to.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  3. Re: alter table doc fix

    Amit Langote <langote_amit_f8@lab.ntt.co.jp> — 2017-10-23T02:52:21Z

    On 2017/10/18 20:37, Alvaro Herrera wrote:
> Amit Langote wrote:
>> Hi.
>>
>> Noticed that a alter table sub-command's name in Description (where it's
>> OWNER) differs from that in synopsis (where it's OWNER TO).  Attached
>> patch to make them match, if the difference is unintentional.
> 
> I agree -- pushed.

Thanks for committing.

> This paragraph
> 
>    <para>
>     The actions for identity columns (<literal>ADD
>     GENERATED</literal>, <literal>SET</literal> etc., <literal>DROP
>     IDENTITY</literal>), as well as the actions
>     <literal>TRIGGER</literal>, <literal>CLUSTER</literal>, <literal>OWNER</literal>,
>     and <literal>TABLESPACE</literal> never recurse to descendant tables;
>     that is, they always act as though <literal>ONLY</literal> were specified.
>     Adding a constraint recurses only for <literal>CHECK</literal> constraints
>     that are not marked <literal>NO INHERIT</literal>.
>    </para>
> 
> is a bit annoying, though I think it'd be worse if we "fix" it to be
> completely strict about the subcommands it refers to.

I didn't notice it in this paragraph before you pointed out, but maybe as
you say, there's not much point in trying to be strict here too.  If we do
fix it though, we might want to do something about TRIGGER, CLUSTER, too,
because there are no sub-commands named just TRIGGER, CLUSTER.

Thanks,
Amit