Thread: pgbench failed when -f option contains a char '@'

pgbench failed when -f option contains a char '@'

From
"Wang, Shenhao"
Date:
Hi, hackers

pgbench use -f filename[@weight] to receive a sql script file with a weight,
but if I create a file contains char'@', like a@2.sql, specify this file without weigth,
pgbench will failed with error:
    pgbench: fatal: invalid weight specification: @2.sql

This action may be unfriendly, because the char '@' is a valid character on Linux
and Windows.

I have created a patch to modify this action. The patch is attached.

Thoughts?

Regards
Shenhao Wang



Attachment

Re: pgbench failed when -f option contains a char '@'

From
Heikki Linnakangas
Date:
On 18/12/2020 08:22, Wang, Shenhao wrote:
> Hi, hackers
> 
> pgbench use -f filename[@weight] to receive a sql script file with a weight,
> but if I create a file contains char'@', like a@2.sql, specify this file without weigth,
> pgbench will failed with error:
>     pgbench: fatal: invalid weight specification: @2.sql
> 
> This action may be unfriendly, because the char '@' is a valid character on Linux
> and Windows.
> 
> I have created a patch to modify this action. The patch is attached.

This patch changes it to first check if the file "a@2.sql" exists, and 
if it doesn't,  only then it tries to interpret it as a weight, as 
filename "a" and weight "2.sql". That stilll doesn't fix the underlying 
ambiguity, though. If you have a file called "script" and "script@1", 
this makes it impossible to specify "script" with weight 1, because "-f 
script@1" will now always open the file "script@1".

I think we should just leave this as it is. The user can simply rename 
the file.

Or maybe one change would be worthwhile here: First check if the part 
after the @ contains only digits. If doesn't, then assume it's part of 
the filename rather than a weight. That would fix this for cases like 
"foo@1.sql", although not for "foo@1".

- Heikki



Re: pgbench failed when -f option contains a char '@'

From
Tom Lane
Date:
Heikki Linnakangas <hlinnaka@iki.fi> writes:
> I think we should just leave this as it is. The user can simply rename 
> the file.

Yeah.  The assumption when we defined the script-weight syntax was that
there's no particular reason to use "@" in a script file name, and
I don't see why that's a bad assumption.

> Or maybe one change would be worthwhile here: First check if the part 
> after the @ contains only digits. If doesn't, then assume it's part of 
> the filename rather than a weight. That would fix this for cases like 
> "foo@1.sql", although not for "foo@1".

I do not like introducing ambiguity of that sort.  Not being entirely
clear on which script file is going to be read seems like a recipe
for security issues.

            regards, tom lane



Re: pgbench failed when -f option contains a char '@'

From
Fabien COELHO
Date:
Hello,

> pgbench use -f filename[@weight] to receive a sql script file with a weight,

ISTM that I thought of this: "pgbench -f filen@me@1" does work.

   sh> touch foo@bla
   sh> pgbench -f foo@bla@1
   pgbench: fatal: empty command list for script "foo@bla"

The documentation could point this out, though.

-- 
Fabien.



Re: pgbench failed when -f option contains a char '@'

From
Fabien COELHO
Date:
Hello Tom,

>> I think we should just leave this as it is. The user can simply rename
>> the file.
>
> Yeah.  The assumption when we defined the script-weight syntax was that
> there's no particular reason to use "@" in a script file name, and
> I don't see why that's a bad assumption.

The "parser" looks for the last @ in the argument, so the simple 
workaround is to append "@1".

I suggest the attached doc update, or anything in better English.

-- 
Fabien.
Attachment

Re: pgbench failed when -f option contains a char '@'

From
Tom Lane
Date:
Fabien COELHO <coelho@cri.ensmp.fr> writes:
> The "parser" looks for the last @ in the argument, so the simple 
> workaround is to append "@1".
> I suggest the attached doc update, or anything in better English.

Agreed, done.

            regards, tom lane