Re: pgbench MAX_ARGS - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: pgbench MAX_ARGS
Date
Msg-id alpine.DEB.2.21.1902261102180.6915@lancre
Whole thread Raw
In response to pgbench MAX_ARGS  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: pgbench MAX_ARGS  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
Hello Simon,

> pgbench has a strange restriction to only allow 10 arguments, which is too
> low for some real world uses.
>
> Since MAX_ARGS is only used for an array of pointers and an array of
> integers increasing this should not be a problem, so increase value to 255.

Fine with me on principle.

Patch applies cleanly, compiles.

However, 3 TAP tests fails on the "too many argument" test case, what a 
surprise:-)

Probably I would have chosen a smaller value, eg 32 or 64, but I have not 
seen your use case.

> While there, correct an off by one error in the error message when you hit
> the limit. The highest argument id is MAX_ARGS - 1, but the max number of
> arguments is MAX_ARGS.

Argh! Indeed.

I notice that there is no documentation update, which just shows that 
indeed there are no documentation about the number of arguments, maybe the 
patch could add a sentence somewhere? There is no limit discussed in the 
PREPARE documentation, I tested up to 20. I'd sugggest to add something at 
the end of the paragraph about variable substitution in the "Custom 
Script" section, eg "A maximum of XX variable references can appear within 
an SQL command.".

-- 
Fabien.


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Remove Deprecated Exclusive Backup Mode
Next
From: Etsuro Fujita
Date:
Subject: Oddity with parallel safety test for scan/join target in grouping_planner