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 1neI3d-0001VU-0K for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Apr 2022 15:03:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1neI3b-0003hM-Qh for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Apr 2022 15:03:51 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1neI3b-0003hD-Hg for pgsql-hackers@lists.postgresql.org; Tue, 12 Apr 2022 15:03:51 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1neI3Z-0006Ed-6C for pgsql-hackers@lists.postgresql.org; Tue, 12 Apr 2022 15:03:50 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 23CF3faO797289; Tue, 12 Apr 2022 11:03:42 -0400 From: Tom Lane To: Fabien COELHO cc: Dean Rasheed , =?ISO-8859-15?Q?Dagfinn_Ilmari_Manns=E5ker?= , PostgreSQL Hackers Subject: Re: random() function documentation In-reply-to: References: <875ynfpiru.fsf@wibble.ilmari.org> <432790.1649702719@sss.pgh.pa.us> <8735ijphrp.fsf@wibble.ilmari.org> <496078.1649704787@sss.pgh.pa.us> Comments: In-reply-to Fabien COELHO message dated "Tue, 12 Apr 2022 10:19:07 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <797287.1649775821.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Tue, 12 Apr 2022 11:03:41 -0400 Message-ID: <797288.1649775821@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Fabien COELHO writes: >>> How about we just say "uses a linear-feedback shift register algorithm"? >> I think it'd be sufficient to just say that it's a deterministic >> pseudorandom number generator. I don't see much value in documenting >> the internal algorithm used. > Hmmm… I'm not so sure. ISTM that people interested in using the random > user-facing variants (only random?) could like a pointer on the algorithm > to check for the expected quality of the produced pseudo-random stream? > See attached. I don't want to get that specific. We were not specific before and there has been no call for such detail in the docs. (Unlike closed-source software, anybody who really wants algorithmic details can find all they want to know in the source code.) It would just amount to another thing to forget to update next time someone changes the algorithm ... which is a consideration that leads me to favor Dean's phrasing. regards, tom lane