Re: extend pgbench expressions with functions

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: extend pgbench expressions with functions
Date: 2016-02-01 08:44:52
Message-ID: alpine.DEB.2.10.1602010857090.6603@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Michaël,

>> - remove the short macros (although IMO it is a code degradation)
>
> FWIW, I like this suggestion from Robert.

I'm not especially found of macros, my main reserve is that because of the
length of the function names this necessarily creates lines longer than 80
columns or awkward and repeated new lines within expressions, which are
both ugly.

> +make_op(const char *operator, PgBenchExpr *lexpr, PgBenchExpr *rexpr)
> +{
> + return make_func(find_func(operator),
> + /* beware that the list is
> reversed in make_func */
> + make_elist(rexpr,
> make_elist(lexpr, NULL)));
> +}
> I think that this should use as argument the function ID, aka PGBENCH_ADD
> or similar instead of find_func() with an operator character. This saves a
> couple of instructions.

Not that simply: The number is the index in the array of functions, not
the enum value, they are currently off by one, and there may be the same
function with different names for some reason some day, so I do not think
it would be a good idea to enforce the order so that they are identical.
Also this minor search is only executed when parsing the script.

> + * - nargs: number of arguments (-1 is a special value for min & max)
> My fault perhaps, it may be better to mention here that -1 means that min
> and max need at least one argument, and that the number of arguments is not
> fixed.

Ok for a better comment.

> For mod() there is no need to have an error, returning 0 is fine. You can
> actually do it unconditionally when rval == -1.

Ok.

> + setDoubleValue(retval, d < 0.0? -d: d);
> Nitpick: lack of spaces between the question mark.

Ok.

> NONE is used nowhere, but I think that you could use it for an assertion
> check here: [...]
> Just replace the "none" message by Assert(type != PGBT_NONE) for example.

I've added a use of the macro.

> Another remaining item: should support for \setrandom be dropped? As the
> patch is presented this remains intact.

As you know my opinion is "yes", but I have not receive a clear go about
that from a committer and I'm not motivated by removing and then re adding
code to the patch.

If nothing clear is said, I'll do a patch just for that one functions are
added and submit it to the next CF.

--
Fabien.

Attachment Content-Type Size
pgbench-funcs-24.patch text/x-diff 40.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2016-02-01 08:45:13 Re: Proposal: Generic WAL logical messages
Previous Message Masahiko Sawada 2016-02-01 08:36:36 Re: Support for N synchronous standby servers - take 2