Yeah I wouldn't say it's worth putting effort in over something that just returns the command name, but the other cases do have some variety to them and would probably be a benefit. I found INSERT to be very odd until I saw its explanation (the OIDs legacy thing).
Is there a command that returns more than one line of input, for example? Other than a SELECT or a DML with a RETURNING clause, of course.
> Thanks Alvaro. Looks cool. So, on the one hand it'd be nice to be able to > auto-generate this once all the commands are standardized into one > structure. That'd be slick.
I thought they were already standardized ... But anyway, I was thinking that this would generate *one* table listing all commands with their tags. I was not thinking in putting the tag in each command's page: I'm not sure that that would be generatable.
> On the other hand, the number of commands in SQL is not that large a > universe, such that it'd be at least somewhat practical to just add Output > as a standard section of the doc page for any command. They number 182 in > both v11, v12 and v13 thus far, and many of those are variations of ALTER, > CREATE or DROP (127 of them, in fact), such that they probably mostly share > an output format. More importantly, the output of each command is unlikely > to change much going forward, certainly not within a major release > (right?). So we could just document each command's output, and if need be > then pull that information into a summary page thereafter, or when the > commit you mention is finished.
I can't say I'm terribly excited about this idea. I won't stop you if you want to pursue it, but I'm not sure I see the value in a RETURN VALUE section that says that the command returns the command name. Maybe it would make sense to have that for the exceptional cases only?
