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.
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 |