Re: Support getrandom() for pg_strong_random() source
От | Masahiko Sawada |
---|---|
Тема | Re: Support getrandom() for pg_strong_random() source |
Дата | |
Msg-id | CAD21AoBn1+qstNdXmB6JjN7Rx9184v11Qsw2s_W0RjzmXtzuUA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Support getrandom() for pg_strong_random() source (Jacob Champion <jacob.champion@enterprisedb.com>) |
Список | pgsql-hackers |
On Thu, Oct 9, 2025 at 5:11 PM Jacob Champion <jacob.champion@enterprisedb.com> wrote: > > On Thu, Oct 9, 2025 at 4:53 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > Does it mean that we introduce something like pg_fast_random() and > > packagers can select it as the random number generation function > > instead of pg_strong_random()? Or can packagers select the function > > used in pg_strong_random()? > > The latter -- packagers should be able to select the implementation of > pg_strong_random(). I think pg_fast_random() is likely to be a bad > abstraction if we don't have more use cases to guide it. Thank you for the clarification. > > > All of these sound reasonable to me. I think we can handle this as two > > separate discussions: one for the UUID implementation changes, and > > another for the pg_strong_random() modifications (which would cover > > both the runtime switching for superusers and the compile-time > > alternatives for packagers). > > Sounds good to me. (Which would you like this thread to be?) I think the second item fits better with the current thread's subject. Having said that, these two items are somewhat related (for example, adding getrandom() support would be a common change for both), so perhaps we can start with the pg_strong_random() changes in this thread? Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: