Thread: boolean states
Hi http://www.postgresql.org/docs/current/static/datatype-boolean.html states: The boolean type can have one of only two states: "true" or "false". A third state, "unknown", is represented by the SQL null value. This sounds like an oxymoron to me. Perhaps that sentence should be changed to: The boolean type can have one of three states: "true" or "false" and "unknown". The third state, "unknown", is represented by the SQL null value. or: The boolean type can have one of three states: "true" or "false" and null. The third state, null, represents the logical value "unknown". Best regards Jack Douglas
On Wed, Apr 27, 2011 at 4:46 AM, Jack Douglas <jack@douglastechnology.co.uk> wrote: > The boolean type can have one of only two states: "true" or "false". > A third state, "unknown", is represented by the SQL null value. > > This sounds like an oxymoron to me. I'm not crazy about that paragraph's confusion between two and three states either, but.. > Perhaps that sentence should be changed > to: > > The boolean type can have one of three states: "true" or "false" and > "unknown". The third state, "unknown", is represented by the SQL null value. > or: > > The boolean type can have one of three states: "true" or "false" and > null. The third state, null, represents the logical value "unknown". I don't think either of these suggested replacements are any better. First, a boolean column can be declared NOT NULL. Second, I don't like the idea of misleading people into thinking that NULL is on equal footing with the other values of a given datatype, particularly as your first alternative implies. I'd vote for just ripping out the: | A third state, "unknown", is represented by the SQL null value. sentence entirely. I see no reason why NULL should be talked about in particular on the page about boolean data types; there are many data types, any of which might be NULL. I almost think it would be worthwhile to have a section in the docs on the (counterintuitive) behaviors of NULL, such as this great post: <http://thoughts.j-davis.com/2009/08/02/what-is-the-deal-with-nulls/> -- or maybe just a link to that page. Josh
> I'd vote for just ripping out the: > | A third state, "unknown", is represented by the SQL null value. > > sentence entirely. I see no reason why NULL should be talked about in > particular on the page about boolean data types; there are many data > types, any of which might be NULL. NULL is not unique to boolean, but UNKNOWN is - it would surely be wrong to have no mention of it at all on this page. This is because the boolean type is the only one used to represent truth (or logical) values. One of the comments from the link you provided: > What’s even more interesting is that for BOOLEAN they invented the > keyword UNKNOWN and the 2003 standard states “The null value of the > boolean data type is equivalent to the Unknown truth value.” So for > BOOLEAN (and only BOOLEAN AFAICT) you’re supposed to say WHERE > <boolean primary> IS [NOT] UNKNOWN. And in the definition of > “literal”, which is supposed to “Specify a non-null value”, “boolean > literal” is equated to TRUE, FALSE or UNKNOWN (but the latter is > equivalent to a “null value” a few pages later).
On Fri, Apr 29, 2011 at 3:29 AM, Jack Douglas <jack@douglastechnology.co.uk> wrote: > NULL is not unique to boolean, but UNKNOWN is - it would surely be wrong to > have no mention of it at all on this page. This is because the boolean type > is the only one used to represent truth (or logical) values. One of the > comments from the link you provided: > >> What’s even more interesting is that for BOOLEAN they invented the keyword >> UNKNOWN and the 2003 standard states “The null value of the boolean data >> type is equivalent to the Unknown truth value.” So for BOOLEAN (and only >> BOOLEAN AFAICT) you’re supposed to say WHERE <boolean primary> IS [NOT] >> UNKNOWN. And in the definition of “literal”, which is supposed to “Specify a >> non-null value”, “boolean literal” is equated to TRUE, FALSE or UNKNOWN (but >> the latter is equivalent to a “null value” a few pages later). Ah, OK - I had forgotten about that SQL syntax. I do agree that this sentence: | A third state, "unknown", is represented by the SQL null value. is particularly confusing, suggesting that "unknown" is a valid boolean literal, on equal footing with "true" and "false". We do document the use of IS [NOT] UNKNOWN already, see: <http://www.postgresql.org/docs/current/interactive/functions-comparison.html> and IMO that page is the appropriate place for such discussion. So maybe we just need a link to that page, and should strip out the confusing sentence about "third state" entirely? Patch attached. Josh
Attachment
On Wed, Apr 27, 2011 at 3:46 AM, Jack Douglas <jack@douglastechnology.co.uk> wrote: > > This sounds like an oxymoron to me. Perhaps that sentence should be changed > to: > > The boolean type can have one of three states: "true" or "false" and > "unknown". if my boolean arithmetic is not wrong the above expression is bad. better expressed is: "true", "false" or "unknown"... -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte y capacitación de PostgreSQL
>> This sounds like an oxymoron to me. Perhaps that sentence should be changed >> to: >> >> The boolean type can have one of three states: "true" or "false" and >> "unknown". > if my boolean arithmetic is not wrong the above expression is bad. > better expressed is: "true", "false" or "unknown"... There are two kinds of people on this earth, those who understand boolean arithmatic and those who don't. I'm not one of them.
Jack Douglas wrote: > There are two kinds of people on this earth, those who understand > boolean arithmatic and those who don't. I'm not one of them. Hmmm... From that, I don't know if you do. Which do I record in the understands_boolean column of the database record for you? Dang, I knew I should have had *two* flags: known_to_understand_boolean and known_to_not_understand_boolean. That would have been much simpler than allowing NULL for UNKNOWN.... -Kevin "When you come to a fork in the road, take it." -Yogi Berra
Kevin Grittner wrote: > Jack Douglas wrote: > > > There are two kinds of people on this earth, those who understand > > boolean arithmatic and those who don't. I'm not one of them. > > Hmmm... From that, I don't know if you do. Which do I record in the > understands_boolean column of the database record for you? Dang, I > knew I should have had *two* flags: known_to_understand_boolean and > known_to_not_understand_boolean. That would have been much simpler > than allowing NULL for UNKNOWN.... Attached patch applied to HEAD and 9.0.X. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml new file mode 100644 index 657835c..c1a34fb *** a/doc/src/sgml/func.sgml --- b/doc/src/sgml/func.sgml *************** *** 82,89 **** <member><literal>NOT</></member> </simplelist> ! <acronym>SQL</acronym> uses a three-valued Boolean logic where the null value represents ! <quote>unknown</quote>. Observe the following truth tables: <informaltable> <tgroup cols="4"> --- 82,90 ---- <member><literal>NOT</></member> </simplelist> ! <acronym>SQL</acronym> uses a three-valued logic system with true, ! false, and <literal>null</>, which represents <quote>unknown</quote>. ! Observe the following truth tables: <informaltable> <tgroup cols="4">
On Mon, May 9, 2011 at 9:04 PM, Bruce Momjian <bruce@momjian.us> wrote: > Attached patch applied to HEAD and 9.0.X. The patch you attached looks like it's a fix for the -bugs thread about "inappropriate reference to boolean logic", not the complaint raised in this thread. Josh
Josh Kupershmidt wrote: > On Mon, May 9, 2011 at 9:04 PM, Bruce Momjian <bruce@momjian.us> wrote: > > Attached patch applied to HEAD and 9.0.X. > > The patch you attached looks like it's a fix for the -bugs thread > about "inappropriate reference to boolean logic", not the complaint > raised in this thread. I see what you mean. I have applied the attached doc patch to HEAD. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml new file mode 100644 index bc1ec3f..ab8eb2d *** a/doc/src/sgml/datatype.sgml --- b/doc/src/sgml/datatype.sgml *************** P <optional> <replaceable>years</>-<repl *** 2784,2792 **** <productname>PostgreSQL</productname> provides the standard <acronym>SQL</acronym> type <type>boolean</type>; see <xref linkend="datatype-boolean-table">. ! The <type>boolean</type> type can have one of only two states: ! <quote>true</quote> or <quote>false</quote>. A third state, ! <quote>unknown</quote>, is represented by the <acronym>SQL</acronym> null value. </para> --- 2784,2792 ---- <productname>PostgreSQL</productname> provides the standard <acronym>SQL</acronym> type <type>boolean</type>; see <xref linkend="datatype-boolean-table">. ! The <type>boolean</type> type can have several states: ! <quote>true</quote>, <quote>false</quote>, and a third state, ! <quote>unknown</quote>, which is represented by the <acronym>SQL</acronym> null value. </para>