Re: [PATCH] random_normal function

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Paul Ramsey <pramsey(at)cleverelephant(dot)ca>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] random_normal function
Date: 2022-12-21 07:47:32
Message-ID: 7372e72e-99ac-d758-1439-198f14dbbf7@mines-paristech.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2022-12-21 07:59:08 Re: pgsql: Doc: Explain about Column List feature.
Previous Message Kyotaro Horiguchi 2022-12-21 07:32:04 Re: (non) translatable string splicing