Re: extend pgbench expressions with functions
От | Michael Paquier |
---|---|
Тема | Re: extend pgbench expressions with functions |
Дата | |
Msg-id | CAB7nPqQbXn+87jb_c7aDPj1RpLGQH=B_XYGC_5yWyNDGKqjmdw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: extend pgbench expressions with functions (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: extend pgbench expressions with functions
|
Список | pgsql-hackers |
On Tue, Jan 12, 2016 at 5:52 PM, Fabien COELHO <coelho@cri.ensmp.fr> wrote: >> 2) When precising a value between 0 and 2, pgbench will loop >> infinitely. For example: >> \set cid debug(random_gaussian(-100, 100, 0)) >> In both cases we just lack sanity checks with PGBENCH_RANDOM, >> PGBENCH_RANDOM_EXPONENTIAL and PGBENCH_RANDOM_GAUSSIAN. I think that >> those checks would be better if moved into getExponentialRand & co >> with the assertions removed. I would personally have those functions >> return a boolean status and have the result in a pointer as a function >> argument. > > > ISTM that if pgbench is to be stopped, the simplest option is just to abort > with a nicer error message from the get*Rand function, there is no need to > change the function signature and transfer the error management upwards. That's fine to me, as long as the solution is elegant. >> I am attaching a patch where I tweaked a bit the docs and added some >> comments for clarity. Patch is switched to "waiting on author" for the >> time being. > > Ok. I'm hesitating about removing the operator management, especially if I'm > told to put it back afterwards. I can understand that, things like that happen all the time here and that's not a straight-forward patch that we have here. I am sure that additional opinions here would be good to have before taking one decision or another. With the current statu-quo, let's just do what you think is best. -- Michael
В списке pgsql-hackers по дате отправления: