Thanks for your analysis.
Regards El mié., 24 jun. 2020 a las 17:17, Tom Lane (<t...@sss.pgh.pa.us>) escribió: > I wrote: > > David Rowley <dgrowle...@gmail.com> writes: > >> I don't often do much with pgbench and variables, but there are a few > >> things that surprise me here. > >> 1) That pgbench replaces variables within single quotes, and; > >> 2) that we still think it's a variable name when it starts with a > digit, and; > >> 3) We replace variables that are undefined. > > > Also (4) this only happens when in non-simple query mode --- the > > example works fine without "-M prepared". > > After looking around in the code, it seems like the core of the issue > is that pgbench.c's parseQuery() doesn't check whether a possible > variable name is actually defined, unlike assignVariables() which is > what does the same job in simple query mode. So that explains the > behavioral difference. > > The reason for doing that probably was that parseQuery() is run when > the input file is read, so that relevant variables might not be set > yet. We could fix that by postponing the work to be done at first > execution of the query, as is already the case for PQprepare'ing the > query. > > Also, after further thought I realize that (1) absolutely is a bug > in the non-simple query modes, whatever you think about it in simple > mode. The non-simple modes are trying to pass the variable values > as extended-query-protocol parameters, and the backend is not going > to recognize $n inside a literal as being a parameter. > > If we fixed (1) and (3) I think there wouldn't be any great need > to tighten up (2). > > regards, tom lane >
