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