Horton

Re: [PATCH] random_normal function

Fabien COELHO <coelho@cri.ensmp.fr>

View thread
From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Michael Paquier <michael@paquier.xyz>
Cc: Paul Ramsey <pramsey@cleverelephant.ca>, Pgsql Hackers <pgsql-hackers@postgresql.org>
Date: 2022-12-21T07:47:32Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Round off random_normal() test results one more decimal place.

  2. Remove pg_regress' never-documented "ignore" feature.

  3. Upgrade the random.sql regression test.

  4. Invent random_normal() to provide normally-distributed random numbers.

Bonjour Michaël,

>> Overall, I think that there should be a clearer discussion and plan about
>> which random functionS postgres should provide to complement the standard
>> instead of going there… randomly:-)
>
> So, what does the specification tells about seeds, normal and random
> functions?  A bunch of DBMSs implement RAND, sometimes RANDOM, SEED or
> even NORMAL using from time to time specific SQL keywords to do the
> work.

I do not have the SQL standard, so I have no idea about what is in there.

From a typical use case point of view, I'd say uniform, normal and 
exponential would make sense for floats. I'm also okay with generating a 
uniform bytes pseudo-randomly.

I'd be more at ease to add simple functions rather than a special 
heavy-on-keywords syntax, even if standard.

> Note that SQLValueFunction made the addition of more returning data
> types a bit more complicated (not much, still) than the new
> COERCE_SQL_SYNTAX by going through a mapping function, so the
> keyword/function mapping is straight-forward.

I'm unclear about why this paragraph is here.

-- 
Fabien.