Re: nextval parameter is not clear

On Thu, 2022-11-24 at 15:50 -0500, Kirk Wolak wrote:
>
> David, let me see how that looks.  From an approach standpoint, I am hearing:
> 1) Keep the example near the definition minimal [just this function]
> 2) It's okay to create an extra "row" [each function is in a <row>], right after the last function, with a detailed example, like you put below!

The detailed example should not be another row in the table. The table is only for
the description of individual functions. The functions "nextval", "setval", "currval"
and "lastval" each have their own row.

I think the elaborate example should be at the bottom of the page, similar to
the "Examples" section in the reference pages. See for example
https://www.postgresql.org/docs/current/sql-createstatistics.html

> David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> > At the bottom of the page I would add an extended example of how these
> > sequences can be used in practice.
> >
> > CREATE TABLE seq_example ( id bigint PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY ) -- implicit sequence named seq_example_seq is created (or whatever is generated...)
> > INSERT INTO seq_example RETURNING id; -- 1
> > SELECT currval('seq_example_seq'::regclass); -- 1

I don't think that is a good example to explain sequences to a beginner.
The sequence behind an identity column is an implementation detail, and
I wouldn't burden the reader with all that.

I think it would be better to create the sequence explicitly and use
it in the DEFAULT clause of a column definition.

> > I would remove the casting of the sequence name from the table examples and just keep one
> > in the main usage example.  I agree that having both to make the reader stop and think is a good idea.

I think that is a good idea, and you should go with that.

Yours,
Laurenz Albe