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

From: shihao zhong <zhong950419(at)gmail(dot)com>
To: Shinya Kato <shinya11(dot)kato(at)gmail(dot)com>
Cc: 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-09 02:05:31
Message-ID: CAGRkXqSuH-=xn8wUrcM3KdYUj+OCqEs_s9e-ax9qDvXhuV_XqA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I tested v2 on master (86f7c82cf10). It builds cleanly and the pgbench
TAP tests pass. Four tests in that file fail on my machine, but they
fail without the patch too.

I confirmed the bug. Neither --continue-on-error nor --max-tries helps.
The old behavior was broken for text substitution as well:
"SELECT 1 WHERE :nv IS NULL;" becomes "WHERE IS NULL" and fails. So I
do not think anyone relies on it.

One doc gap: 0001 changes what \gset does with a NULL column, but the \gset
docs say nothing about NULL. One sentence is enough, so no v3 is
needed. Master only, no back-patch.

Please commit 0002 together with 0001. Patch 0001 says a captured NULL
can be tested with IS NULL, but that test cannot tell a real NULL from
a column holding the text 'NULL'. Only 0002 explains this.

As CommitFest manager I am moving
https://commitfest.postgresql.org/patch/7163/ to Ready for Committer,

Thanks,
Shihao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Haibo Yan 2026-09-09 02:18:13 Re: Global temporary tables
Previous Message Richard Guo 2026-09-09 01:38:41 Re: Assert failure in try_nestloop_path()