Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oyTK4-0003vJ-Rr for pgsql-docs@arkaria.postgresql.org; Fri, 25 Nov 2022 07:40:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oyTK3-0004Fi-Hm for pgsql-docs@arkaria.postgresql.org; Fri, 25 Nov 2022 07:40:31 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oyTK3-00049k-9R for pgsql-docs@lists.postgresql.org; Fri, 25 Nov 2022 07:40:31 +0000 Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oyTK0-00063n-UC for pgsql-docs@lists.postgresql.org; Fri, 25 Nov 2022 07:40:30 +0000 Received: by mail-wr1-x42f.google.com with SMTP id v1so5472531wrt.11 for ; Thu, 24 Nov 2022 23:40:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=Szpb+0LScB1vZB1nRL0lLnGpPfSUOSqKdyYG9m17Q6Y=; b=NWhvfexFpYVxYJDkFMINOOJEv7n5v0r1HjhTtJfbhFL/7L+PAOnMHxiLiFUiN+yBh4 nzUZA+Yc6wTmqqBlmjUVWe/pAVEFiedYNQKbcmf6xJ9Ok3uyK/IJ+ATU1VptXO9lPHde TxSEBUBi0kR2cJyfVUgzSZKIK9T0lgckupMt2Ux7Uu+uBsyxEG7ilyoJcQkMUAgYVJTb LW9qBo8D2+AHHL2Jz+sdW8EJ1eO0HoutVQUUjRcIE8JVpFJeqRoCPVFiTWEa3jYeAikN dsFxlwy7Da4alZqO+LhiylLb7VGkXwhMxU6167MyBMJW2jBkbJZE9bZEfzhRvrpbzPM3 ZlxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Szpb+0LScB1vZB1nRL0lLnGpPfSUOSqKdyYG9m17Q6Y=; b=oVMpx4C933z/RJB54wbdXDlA3uHM7scB7baFmNZrwzhc/RUFBKUlABPBLLKQRTDlnz D+n3/iF/XcH/+yC1YcgXW7AVoLUix5QyQxkYJ1FZVcyUTRz4DuEBnT14WVVSPT4G9fwP wAGGfDNinSW/RzFNmNjPJ5osxvr/WwlnbQz67Gc+C2S9ClyWt+uFY9X4Oifx2M7pSveo gP/H5acvTStF3GyOlUsh4yDbgnuFPIAxUFFd3lRRwc1JUjTNm+GxCfxz8w4M27ijqgwC XjpUzFWPS7WvVJcPLzOJHzgZlEHmYTkW/zIyP6j13RWVALs6vIBwtATfirwVSQ1/aTCZ aw8A== X-Gm-Message-State: ANoB5pn3lV6eVDa+ZMPSI0nXgzcrsy65ZM/8g9N/7m8WRlTS/qv9SHOh SpBEeYYMmS1Mao8Gfgkk46owhg== X-Google-Smtp-Source: AA0mqf7KJhLCY9gjUy0Rhz+Bt9it/NCkTyatSUtr8SvppmE2wluyhXIWT0TlNhQJmEWPvkXzopTRVw== X-Received: by 2002:a5d:5914:0:b0:236:57f3:c9e6 with SMTP id v20-20020a5d5914000000b0023657f3c9e6mr22001311wrd.21.1669362026935; Thu, 24 Nov 2022 23:40:26 -0800 (PST) Received: from localhost.localdomain (mobiledyn-62-240-134-189.mrsn.at. [62.240.134.189]) by smtp.gmail.com with ESMTPSA id j15-20020a5d452f000000b002416e383e1csm3126997wra.25.2022.11.24.23.40.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Nov 2022 23:40:26 -0800 (PST) Message-ID: <0c0eddb287571e72a2df1be8758fbbb0cb7cc378.camel@cybertec.at> Subject: Re: nextval parameter is not clear From: Laurenz Albe To: Kirk Wolak , "David G. Johnston" Cc: Bruce Momjian , ailjushkin@gmail.com, pgsql-docs@lists.postgresql.org Date: Fri, 25 Nov 2022 08:40:25 +0100 In-Reply-To: References: <166608103231.2042183.13992576112735261253@wrigleys.postgresql.org> <21e017222199f3ca397fa70549140d226236e4b6.camel@cybertec.at> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 (3.42.4-2.fc35) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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 ], 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 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