Andres Freund <and...@anarazel.de> writes:
> Definitely shouldn't be the same in all cases, but I think there's a decent
> number of cases where they can be the same. The differences between the two is
> often minimal today.
>
> Entirely randomly chosen example:
>
> { oid => '2825',
> descr => 'slope of the least-squares-fit linear equation determined by the
> (X, Y) pairs',
> proname => 'regr_slope', prokind => 'a', proisstrict => 'f',
> prorettype => 'float8', proargtypes => 'float8 float8',
> prosrc => 'aggregate_dummy' },
>
> and
>
> <row>
> <entry role="func_table_entry"><para role="func_signature">
> <indexterm>
> <primary>regression slope</primary>
> </indexterm>
> <indexterm>
> <primary>regr_slope</primary>
> </indexterm>
> <function>regr_slope</function> ( <parameter>Y</parameter>
> <type>double precision</type>, <parameter>X</parameter> <type>double
> precision</type> )
> <returnvalue>double precision</returnvalue>
> </para>
> <para>
> Computes the slope of the least-squares-fit linear equation determined
> by the (<parameter>X</parameter>, <parameter>Y</parameter>)
> pairs.
> </para></entry>
> <entry>Yes</entry>
> </row>
>
>
> The description is quite similar, the pg_proc entry lacks argument names.
>
>
>> This sounds to me like it would be a painful exercise with not a
>> lot of benefit in the end.
>
> I think the manual work for writing signatures in sgml is not insignificant,
> nor is the volume of sgml for them. Manually maintaining the signatures makes
> it impractical to significantly improve the presentation - which I don't think
> is all that great today.
And it's very inconsistent. For example, some functions use <optional>
tags for optional parameters, others use square brackets, and some use
<literal>VARIADIC</literal> to indicate variadic parameters, others use
ellipses (sometimes in <optional> tags or brackets).
> And the lack of argument names in the pg_proc entries is occasionally fairly
> annoying, because a \df+ doesn't provide enough information to use functions.
I was also annoyed by this the other day (specifically wrt. the boolean
arguments to pg_ls_dir), and started whipping up a Perl script to parse
func.sgml and generate missing proargnames values for pg_proc.dat, which
is how I discovered the above. The script currently has a pile of hacky
regexes to cope with that, so I'd be happy to submit a doc patch to turn
it into actual markup to get rid of that, if people think that's a
worhtwhile use of time and won't clash with any other plans for the
documentation.
> It'd also be quite useful if clients could render more of the documentation
> for functions. People are used to language servers providing full
> documentation for functions etc...
A more user-friendly version of \df+ (maybe spelled \hf, for symmetry
with \h for commands?) would certainly be nice.
> Greetings,
>
> Andres Freund
- ilmari
