Re: Summary of DDL/DML statement return/output values?

[Steve Estes]

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.

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.

Just seemed like a standard thing that software docs cover - like how the
documentation of a programming language's function library always mentions
what is returned by each function (even if nothing).

-Steve


On Mon, Jun 22, 2020 at 1:43 PM Alvaro Herrera 
wrote:

> On 2020-Jun-22, Steve Estes wrote:
>
> > However, for some statements PG's output format is documented (e.g.
> INSERT
> > , EXPLAIN
> > ), and in others
> it is
> > not (e.g. SET , CREATE
> > TABLE , ALTER
> TABLE
> > , etc).  The
> > output-control RETURNING clause gets its own page
> > , but I'm
> unaware of
> > any other meta-summary of output values.
> >
> > *Is there a summary of what PG returns in response to each of the various
> > statements that it supports?  If not, should there be?*
>
> I think starting with commit 2f9661311b83 it might be possible to create
> such a table.  I'm wary of documenting this painting us into a corner
> forever, though.
>
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=2f9661311b83dc481fc19f6e3bda015392010a40
>
> --
> Álvaro Herrerahttps://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>

Re: Summary of DDL/DML statement return/output values?

[Alvaro Herrera]

On 2020-Jun-23, Steve Estes wrote:

> 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?

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Summary of DDL/DML statement return/output values?

[Steve Estes]

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.

On Tue, Jun 23, 2020 at 4:01 PM Alvaro Herrera 
wrote:

> On 2020-Jun-23, Steve Estes wrote:
>
> > 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?
>
> --
> Álvaro Herrerahttps://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>