Re: pgbench and timestamps
От | Tom Lane |
---|---|
Тема | Re: pgbench and timestamps |
Дата | |
Msg-id | 2206076.1593011840@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgbench and timestamps (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgbench and timestamps
Re: pgbench and timestamps |
Список | pgsql-general |
I wrote: > David Rowley <dgrowleyml@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
В списке pgsql-general по дате отправления: