Re: Logical Implication

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Vik Fearing <vik(at)postgresfriends(dot)org>
Cc: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Isaac Morland <isaac(dot)morland(at)gmail(dot)com>
Subject: Re: Logical Implication
Date: 2026-11-09 20:50:21
Message-ID: avIyDcgAN1YufY1U@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 06, 2026 at 02:05:23PM -0600, Nathan Bossart wrote:
> On Tue, Oct 06, 2026 at 01:19:31PM -0500, Nathan Bossart wrote:
>> On Sat, Oct 03, 2026 at 06:18:43PM +0200, Vik Fearing wrote:
>>> <acronym>SQL</acronym> uses a three-valued logic system with true,
>>> - false, and <literal>null</literal>, which represents <quote>unknown</quote>.
>>> - Observe the following truth tables:
>>> + false, and unknown; the null value of a <type>boolean</type> and the truth
>>> + value unknown are one and the same. In the truth tables below the left
>>> + operand of a binary operator selects the row, and the right operand the
>>> + column:
>>
>> I find the reorganization to be an improvement, and I intend to commit this
>> one sooner than later. The only thing I'd change is the switch from NULL
>> to "unknown" in the tables. Users deal with NULL at the command level, and
>> the rest of the docs use NULL, so I think the existing text has the right
>> idea by noting once that NULL represents "unknown" and then using NULL
>> throughout.
>
> Concretely, like the attached.

I've committed this one.

--
nathan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kirill Reshke 2026-11-09 21:10:41 Re: Reduce build times of pg_trgm GIN indexes
Previous Message Masahiko Sawada 2026-11-09 20:04:38 Assertion failure in update_local_synced_slot(), slotsync.c:364