Re: pgbench: \gset and \aset should store SQL NULL as the null value

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: shihao zhong <zhong950419(at)gmail(dot)com>
Cc: Shinya Kato <shinya11(dot)kato(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pgbench: \gset and \aset should store SQL NULL as the null value
Date: 2026-09-10 04:15:58
Message-ID: aqIu_ozs_t6IhK4U@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 09, 2026 at 02:23:35PM +0900, Michael Paquier wrote:
> Similarly to Horiguchi-san's comments, I think that the tests could be
> trimmed even more. I see no need for at least:
> - "gset NULL interpolates as SQL NULL"
> - "gset empty string stays empty"
> - "gset NULL is bound as the string NULL in extended and prepared
> modes"

Yeah, I'm still unconvinced by the value brought here in terms of
cross-checking an actual NULL and a NULL but written as a string. The
first test proposed is also good enough to check that we generate a
NULL variable through setNullValue()->putVariableValue(). So kept
only the first test, applied the result.

> At the end I would just keep the "pgbench gset command with NULL" bit,
> which should be enough to cover readCommandResponse(), no? No need to
> be fancy, efficient is fine and saves runtime cycles.

Ditto about the doc suggestion. If somebody is excited enough about
this part, please feel free..
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-09-10 04:25:06 Re: pgstat: Flush some statistics within running transactions, take 2
Previous Message Noah Misch 2026-09-10 03:59:53 Re: pg_get_*_ddl() needs a redesign