Re: pgbench - test whether a variable exists

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgbench - test whether a variable exists
Date: 2020-04-14 05:49:49
Message-ID: alpine.DEB.2.21.2004140730540.27777@pseudo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Bonjour Michaël,

> Hmm. It seems to me that this stuff needs to be more careful with the
> function handling? For example, all those cases fail but they directly
> pass down a variable that may not be defined, so shouldn't those results
> be undefined as well instead of failing:

> \set g double(:{?no_such_variable})
> \set g exp(:{?no_such_variable})
> \set g greatest(:{?no_such_variable}, :{?no_such_variable})
> \set g int(:{?no_such_variable})

I do not understand: All the above examples are type errors, as ":{?var}"
is a boolean, that cannot be cast to double, be exponentiated etc. So
failing just seems appropriate.

Maybe casting boolean to int should be allowed, though, as pg does it.

> It seems to me that there could be a point in having the result of any
> function to become undefined if using at least one undefined argument
> (the point could be made as well that things like greatest just ignore
> conditioned variables), so I was surprised to not see the logic more
> linked with ENODE_VARIABLE.

Hmmm… :var (ENODE_VARIABLE) replaces de variable by its value, and it
fails if the variable is not defined, which is the intention, hence the
point of having the ability to test whether a variable exists, and its new
expression node type.

It could replace it by NULL when not existing, but ISTM that a script can
wish to distinguish NULL and undefined, and it departs from SQL which just
fails on a undefined alias or column or whatever.

If someone wants to go back to having a self propagating NULL, they can

\if :{?var}
\set var NULL


\set var CASE WHEN :{?var} THEN :var ELSE NULL END

to get it.

Having some special UNDEF value looks unattractive, as it would depart for
SQL even further.

> If your intention is to keep this behavior, it should at least be tested
> I guess.

My intention is to keep failing on type errors, but maybe I'm missing
something of your point.

> Please note that this patch will have to wait until v14 opens
> for business for more.

Sure. I put it in the July CF, and I do not expect to it to be processed
on the first CF it appears in.


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2020-04-14 06:34:11 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
Previous Message Michael Paquier 2020-04-14 05:47:54 Re: doc review for v13