Hello Tom,
The attached patch fixes some of the underlying problems reported by
delaying the :var to $1 substitution to the last possible moments, so that
what variables are actually defined is known. PREPARE-ing is also delayed
to after these substitutions are done.
It requires a mutex aro
Thanks for your analysis.
Regards
El mié., 24 jun. 2020 a las 17:17, Tom Lane () escribió:
> I wrote:
> > David Rowley 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 quo
I'll look into it. Thanks for the analysis and CC-ing.
--
Fabien.
I wrote:
> David Rowley 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 repla
David Rowley writes:
> On Wed, 24 Jun 2020 at 20:41, Jaime Soler wrote:
>> I don't know why pgbench use timestamp: «2006-03-01 00$1$2» instead of
>> timestamp '2006-03-01 00:00:00'
> I've not debugged it, but it looks like pgbench thinks that :00 is a
> pgbench variable and is replacing each i
Hi,
Thanks for your comments, I worked around that problem because I was able
to truncate the timestamp and use only the date part , alsoit might
works the use of to_timestamp. But I would like to understand what is
happening , I realized that pgbench is identified erroneously the minutes
and se
On Wed, 24 Jun 2020 at 20:41, Jaime Soler wrote:
>
> Hi, does anybody know what is wrong with pgbench in this case ?. Here is a
> simple query to generate a random date in a interval time.sql:
>
> (select timestamp '2005-09-01' + random() * ( timestamp '2006-03-01
> 00:00:00' - timestamp '2005
