Re: documentation structure - Mailing list pgsql-hackers
From | Andres Freund |
---|---|
Subject | Re: documentation structure |
Date | |
Msg-id | 20240416201700.wyz7ojp3fr7222xt@awork3.anarazel.de Whole thread Raw |
In response to | Re: documentation structure (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: documentation structure
|
List | pgsql-hackers |
Hi, On 2024-04-16 15:05:32 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > I think we should work on generating a lot of func.sgml. Particularly the > > signature etc should just come from pg_proc.dat, it's pointlessly painful to > > generate that by hand. And for a lot of the functions we should probably move > > the existing func.sgml comments to the description in pg_proc.dat. > > Where are you going to get the examples and text descriptions from? I think there's a few different way to do that. E.g. having long_desc, example fields in pg_proc.dat. Or having examples and description in a separate file and "enriching" that with auto-generated function signatures. > (And no, I don't agree that the pg_description string should match > what's in the docs. The description string has to be a short > one-liner in just about every case.) 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 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. 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... Greetings, Andres Freund
pgsql-hackers by date: