> Instead of a note maybe add a paragraph stating: > > "This setting is ignored when multiple statements are sent to the server as a single command (i.e., via the -c command line option or the \; meta-command). Additionally, it is possible for certain combinations of statements sent in that manner to instead return no results, or even be ignored, instead of returning the result set of the last query. In short, when FETCH_COUNT is non-zero, and you send a multi-statement command to the server, the results are undefined. This combination in presently allowed for backward compatibility."
I personally dislike documenting things that don't work, if worded in a way that don't leave open the possibility of fixing it in the future. So I didn't like Fabien's original wording either, though I was thinking that just adding "This may change in a future release of Postgres" might have been enough. That seems more difficult with your proposed wording, but maybe you see a good way to do it?
After rereading it a few times, I think it's too specific about how it fails. Maybe it's possible to reduce to just the last two phrases, along the lines of
> When FETCH_COUNT is non-zero, and you send a multi-statement command > to the server (for example via -c or the \; meta-command), the results > are undefined. This combination in presently allowed for backward > compatibility and may be changed in a future release.
Everything may change in a future release so I am generally opposed to including that. But I'm ok with being less descriptive on the observed failure modes and sweeping it all under "undefined". Need to fix my typo, "This combination is presently allowed".
When FETCH_COUNT is non-zero, and you send a multi-statement command to the server (for example via -c or the \; meta-command), the results are undefined. This combination is presently allowed for backward compatibility.
