Re: pgbench - test whether a variable exists - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pgbench - test whether a variable exists
Date
Msg-id 20200414010151.GC1492@paquier.xyz
Whole thread Raw
In response to Re: pgbench - test whether a variable exists  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: pgbench - test whether a variable exists  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
On Mon, Apr 13, 2020 at 09:54:01AM +0200, Fabien COELHO wrote:
> Attached a v4. I'm resurrecting this small patch, after "\aset" has been
> added to pgbench (9d8ef988).

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})

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.  If your intention is to keep this
behavior, it should at least be tested I guess.  Please note that this
patch will have to wait until v14 opens for business for more
comments.  :p
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_basebackup, manifests and backends older than ~12
Next
From: Michael Paquier
Date:
Subject: Re: [patch] some PQExpBuffer are not destroyed in pg_dump