Re: extend pgbench expressions with functions
От | Fabien COELHO |
---|---|
Тема | Re: extend pgbench expressions with functions |
Дата | |
Msg-id | alpine.DEB.2.10.1602161400570.2638@sto обсуждение исходный текст |
Ответ на | Re: extend pgbench expressions with functions (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: extend pgbench expressions with functions
|
Список | pgsql-hackers |
Hello Robert, >> However, for obvious reasons the committer opinion prevails:-) > > You're welcome to solicit other opinions. I'm not unwilling to give > way if there's a chorus of support for the way you've done it. Hmmm. I do not expect much chorus on such a minor subject:-) > But to me it sounds like you're saying that it doesn't really matter > whether the system is scalable and maintainable because we only have 5 > functions right now, which is a design philosophy with which I just > don't agree. The design does not aim at scalability but at simplicity, otherwise I would have done things quite differently: with many functions the "switch" based selection does not scale anyway. Anyway, attached are two patches, one for each approach. The array (second patch) is not too bad if one agrees with a maximum number of arguments, and also as I did not change the list structure coming from the parser, so it does not need to manage the number of arguments in the function structure. The code for min/max is also simpler when dealing with an array instead of a linked list. I do not like much array references in the code, so I tried to avoid them by using lval/rval scalars for operator operands. Please choose the one you prefer, and I'll adapt the remaining stuff to your choice. -- Fabien.
В списке pgsql-hackers по дате отправления: