Обсуждение: minor doc fix - garbage in example of result of unnest

Поиск
Список
Период
Сортировка

minor doc fix - garbage in example of result of unnest

От
Pavel Stehule
Дата:
Hi

diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 7c06afd3ea..3b810c0eb4 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -17821,7 +17821,6 @@ SELECT NULLIF(value, '(none)') ...
  1
  2
 </programlisting>
-        (2 rows in result)
        </para></entry>
       </row>

Regards

Pavel

Re: minor doc fix - garbage in example of result of unnest

От
Tom Lane
Дата:
Pavel Stehule <pavel.stehule@gmail.com> writes:
> diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
> index 7c06afd3ea..3b810c0eb4 100644
> --- a/doc/src/sgml/func.sgml
> +++ b/doc/src/sgml/func.sgml
> @@ -17821,7 +17821,6 @@ SELECT NULLIF(value, '(none)') ...
>   1
>   2
>  </programlisting>
> -        (2 rows in result)
>         </para></entry>
>        </row>

That's not "garbage", I put it there intentionally.

            regards, tom lane



Re: minor doc fix - garbage in example of result of unnest

От
Tomas Vondra
Дата:
On Fri, Jun 05, 2020 at 09:56:54AM -0400, Tom Lane wrote:
>Pavel Stehule <pavel.stehule@gmail.com> writes:
>> diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
>> index 7c06afd3ea..3b810c0eb4 100644
>> --- a/doc/src/sgml/func.sgml
>> +++ b/doc/src/sgml/func.sgml
>> @@ -17821,7 +17821,6 @@ SELECT NULLIF(value, '(none)') ...
>>   1
>>   2
>>  </programlisting>
>> -        (2 rows in result)
>>         </para></entry>
>>        </row>
>
>That's not "garbage", I put it there intentionally.
>

Why is it outside the <programlisting> though? Also, the next unnest
example does not include the number of rows - why the difference?


-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: minor doc fix - garbage in example of result of unnest

От
"David G. Johnston"
Дата:
On Fri, Jun 5, 2020 at 8:38 AM Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
On Fri, Jun 05, 2020 at 09:56:54AM -0400, Tom Lane wrote:
>Pavel Stehule <pavel.stehule@gmail.com> writes:
>> diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
>> index 7c06afd3ea..3b810c0eb4 100644
>> --- a/doc/src/sgml/func.sgml
>> +++ b/doc/src/sgml/func.sgml
>> @@ -17821,7 +17821,6 @@ SELECT NULLIF(value, '(none)') ...
>>   1
>>   2
>>  </programlisting>
>> -        (2 rows in result)
>>         </para></entry>
>>        </row>
>
>That's not "garbage", I put it there intentionally.
>

Why is it outside the <programlisting> though? Also, the next unnest
example does not include the number of rows - why the difference?

More generally I think the final unnest listing is probably the best presentation for a set-returning function, and the one under discussion should be consistent with it.  The function reference documentation doesn't seem like a place to introduce strictly psql output variations like /pset footer on|off.  A set-returning function should be displayed in the example output as a structured table like the last unnest example.  I don't think it's necessary for "single column" sets to be an exception.  Since the examples convert null to (none) there isn't even whitespace concerns in the output where you want to display a bottom boundary for clarity.

Related, It seems arbitrary that the case-related full block examples do not have row counts but the aggregate full block examples do.

I don't see where having the row counts in the output adds clarity and it just more text for the reader to mentally filter out.

David J.

Re: minor doc fix - garbage in example of result of unnest

От
Tom Lane
Дата:
"David G. Johnston" <david.g.johnston@gmail.com> writes:
>> On Fri, Jun 05, 2020 at 09:56:54AM -0400, Tom Lane wrote:
>>> That's not "garbage", I put it there intentionally.

> I don't see where having the row counts in the output adds clarity and it
> just more text for the reader to mentally filter out.

Seems like I'm getting outvoted here.  If there aren't other votes,
I'll change it.

            regards, tom lane