From: | "Joel Jacobson" <joel(at)compiler(dot)org> |
---|---|
To: | "jian he" <jian(dot)universality(at)gmail(dot)com> |
Cc: | "Tomas Vondra" <tomas(dot)vondra(at)enterprisedb(dot)com>, "Tom Dunstan" <pgsql(at)tomd(dot)cc>, "Andrew Dunstan" <andrew(at)dunslane(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Do we want a hashset type? |
Date: | 2023-06-20 10:59:32 |
Message-ID: | a5e83c63-c3ae-4422-9606-cb0f66eaa741@app.fastmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 19, 2023, at 02:00, jian he wrote:
> select hashset_contains('{1,2}'::int4hashset,NULL::int);
> should return null?
I agree, it should.
I've now changed all functions except int4hashset() (the init function)
and the aggregate functions to be STRICT.
I think this patch is OK to send as an incremental one, since it's an isolated change:
Apply STRICT to hashset functions; clean up null handling in hashset-api.c
Set hashset functions to be STRICT, thereby letting the system reject null
inputs automatically. This change reflects the nature of hashset as an
implementation of a set-theoretic system, where null values are conceptually
unusual.
Alongside, the hashset-api.c code has been refactored for clarity, consolidating
null checks and assignments into single lines.
A 'strict' test case has been added to account for these changes.
/Joel
Attachment | Content-Type | Size |
---|---|---|
hashset-0.0.1-1ee0df0.patch | application/octet-stream | 19.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Jelte Fennema | 2023-06-20 11:42:13 | Re: Deleting prepared statements from libpq. |
Previous Message | Amit Kapila | 2023-06-20 10:22:17 | Re: Synchronizing slots from primary to standby |