Pavel Stehule <pavel.steh...@gmail.com> writes: > po 5. 10. 2020 v 15:56 odesÃlatel Thomas Kellerer <sham...@gmx.net> napsal: >> So instead of >> make_interval ( [ year int [, month int [, week int [, day int [, hour >> int [, min int [, sec double precision ]]]]]]] ) >> it should be >> make_interval ( [ years int [, months int [, weeks int [, days int >> [,hours int [, mins int [, secs double precision ]]]]]]] )
Right, fixed. > this syntax is not correct too > It should be > make_interval( years int default 0, month int default 0, days int > default 0, hours int default 0, secs double precision default 0) IIRC, I intentionally changed that in v13; the existence of the defaults is sufficiently covered by the text "... fields, each of which can default to zero". I think that was partly motivated by trying to get the function signature to fit into limited space. The final docs-table design we ended up with might allow undoing it, but I don't see any real reason to. The other way is more verbose and not any clearer. I spent a little bit of time scanning for other discrepancies between func.sgml and pg_proc.proargnames, and found several, mostly though not exclusively in the JSON functions. In these other cases, though, I think there might be a good argument for making pg_proc fit the docs not the other way around. In the JSON functions, for example, pg_proc randomly has some functions calling the main JSON[B] input "target" while others call it "from_json" or "json_in". I'm not real sure which of those names is preferable, but inconsistency is not preferable. regards, tom lane