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:
Show quoted text
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
Attachments:
boolean_unknown.patchapplication/octet-stream; name=boolean_unknown.patchDownload+4-4
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
Import Notes
Resolved by subject fallback
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. +
Attachments:
/rtmp/difftext/x-diffDownload+5-5
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. +