From: | Oliver Rice <oliver(at)oliverrice(dot)com> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Inconsistent application of [, ...] in documentation |
Date: | 2021-01-27 22:16:09 |
Message-ID: | CAKYAq64f6xTnCV1qBKPY=6k-_h_zvfkEva=AstSOABTYRm5=AQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Would contributions to synopsis documentation attempting to increase
consistency and accuracy be considered provided they don't negatively
impact readability?
Oliver
On Wed, Jan 27, 2021 at 11:59 AM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> On Wed, Jan 27, 2021 at 10:37 AM Oliver Rice <oliver(at)oliverrice(dot)com>
> wrote:
>
>>
>> "( first_param TEXT, second_param TEXT )"
>>
>> Incorrect Usage:
>>
>> "( first_param TEXT, TEXT)"
>>
>>
>> --
>>
>> So in Variant A, "[, ...]" is intended to apply to the immediately preceding token but in variant B it is intended to apply to all preceding tokens in the same group.
>>
>>
>> But (TEXT, TEXT) is valid.
>
> The reality is that there is a trade-off between explicitness and
> readability (human usability). Complaints strictly about inconsistency are
> not going to be acted upon. Specific documentation will be improved upon
> given sufficient demonstration of a usability problem AND the available of
> a more usable alternative. That the wrong choice will simply "fail fast" in
> cases where the capturing of the repetition is ambiguous, and there are
> examples to make clear which is correct, causes one to err on the side of
> readability for the synopsis (which is unique to each command) rather than
> consistency between commands.
>
> David J.
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2021-01-27 22:33:37 | Re: Inconsistent application of [, ...] in documentation |
Previous Message | Alvaro Herrera | 2021-01-27 21:57:52 | Re: BUG #16794: BEFORE UPDATE FOR EACH ROW triggers on partitioned tables can break tuple moving UPDATEs |