From: Andy Fan <zhihuifan1213@163.com>
To: Aleksander Alekseev <aleksander@timescale.com>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>,  Dean Rasheed
 <dean.a.rasheed@gmail.com>,  Japin Li <japinli@hotmail.com>,  Jim Jones
 <jim.jones@uni-muenster.de>
Subject: Re: New function normal_rand_array function to contrib/tablefunc.
In-Reply-To: 
 <CAJ7c6TPw3tD3PJneqZdfmauqx8qW3yeLw7WY3NucNavjDzdpyA@mail.gmail.com>
	(Aleksander Alekseev's message of "Tue, 5 Nov 2024 20:35:31 +0300")
References: <87plssezpc.fsf@163.com>
	<fd1de8c0-467b-4a41-8f7b-0d5122676ecb@uni-muenster.de>
	<CAEZATCX_Rd24mS4ScEYV=cLKMoQEJX=+oq40kYbok8rw211W8g@mail.gmail.com>
	<87v814wmz0.fsf@163.com>
	<CAEZATCUMvnFMiYJbDvk4d1nDdZ8VEqZWOjTUUZZ3itowGyB42w@mail.gmail.com>
	<87plpv1rb0.fsf@163.com> <87le0iqrsu.fsf@163.com>
	<ME0P300MB04456793A234B3B1A2B77882B6942@ME0P300MB0445.AUSP300.PROD.OUTLOOK.COM>
	<87zfox2rx7.fsf@163.com>
	<ME0P300MB044589098B6FB20AA771C97DB6952@ME0P300MB0445.AUSP300.PROD.OUTLOOK.COM>
	<87ed68gcym.fsf@163.com>
	<CAEZATCXZt1sUuT4SdZo5vn1rJtm2Rp3UCUsH2YzyBt-vHRXrrQ@mail.gmail.com>
	<87ldyojxwg.fsf@163.com>
	<CAEZATCVnsyJNG1FqyCKPkVmx0V6PO2Xz5KTwRR1EUcsTnBb=yQ@mail.gmail.com>
	<87ses7rfc2.fsf@163.com>
	<CAJ7c6TNO_a0RZdV68TzaxRur1=Hcuxo7zyYGnxCMUnbfChyAZA@mail.gmail.com>
	<CAJ7c6TO8N4hE7zFKrf90uyS1ct+UCEzYuzq6=pG=e4eZykwRgQ@mail.gmail.com>
	<CAEZATCX9SeH-q8zaqjh8m=m7_RYFcLJLRSZ8fVvB1MbZ7pQQMA@mail.gmail.com>
	<CAJ7c6TOhwhK1=s9mwaSQy2jWvban1OZ4rz7_pLCvb+NbdiQ6Wg@mail.gmail.com>
	<CAEZATCWCOCQQe2vDt2T0whFP09RR=OSrvqYE2Y631mcL98m1eg@mail.gmail.com>
	<CAJ7c6TPw3tD3PJneqZdfmauqx8qW3yeLw7WY3NucNavjDzdpyA@mail.gmail.com>
Date: Thu, 07 Nov 2024 08:51:15 +0800
Message-ID: <87zfmbq324.fsf@163.com>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://www.postgresql.org/message-id/87zfmbq324.fsf%40163.com>
Precedence: bulk


Hi,

Looks I miss some interesting dicussions in the recent days, the
pretty neat API random_array, random_array or array_random (I prefer the
random_array because of the setseed stuff as Dean said). These
dicussions absoluatly enrichs my API / decoument design experience. 

I'm still not sure if it should be put into core, I agree that 
random_array/array_random should be put into core if we go with this
way. It looks to me that the cost of putting them into core is just
it takes more OIDs in initdb, hence making catalog a bit of bigger, not 
sure the real matter of it.

As for if we should support random_array_multidim at the first step, as
a developer, I would like to try dim sutff since I have little
experience on this area, It is possible that this area bring some
other interesting experience for me as the things happen to me recently.


> I suggest implementing the function in several steps. First implement
> random_array(min, max, len). It's straightforward and IMO will provide
> the most value to the majority of the users.Then we can either add an
> optional argument or a random_array_multidim() function.

This may doubles the OID expence, every invariants needs 3 OIDs(int, bigint,
numeric). 

> This can be
> implemented and discussed as a separate patch. This approach would be
> convenient for the author and the reviewers and also will allow us to
> deliver value to the users sooner.

Appricated for your suggestion like this, Aleksander, I can understand
your kindly intention!

If no new ideas, I will defer to Dean's final decision for efficient
purpose.

-- 
Best Regards
Andy Fan