Forum Stats

  • 3,837,059 Users
  • 2,262,222 Discussions
  • 7,900,194 Comments

Discussions

New type BOOLEAN

135678

Comments

  • William Robertson
    William Robertson Member Posts: 9,568 Bronze Crown

    It's fairly heavy going I admit, especially as it get's into the mathematics of implied logic.

    Not sure how that would change Tom's suggestion to use 0 and 1 etc.

    Jeez, now you've even got me questioning it. LOL!  Gonna have to go and clarify things for myself again now.....

    BluShadow wrote:
    
    Not sure how that would change Tom's suggestion to use 0 and 1 etc.
    

    Well, if Boolean logic is fundamentally invalidated by null values then that will be a problem regardless of what symbols we use for TRUE and FALSE.

    ApexBineGbenga Ajakayejaramill
  • William Robertson
    William Robertson Member Posts: 9,568 Bronze Crown
    edited May 12, 2016 2:47PM

    To be honest, there's little point in me regurgitating what is already out there on the web.

    Joe Celko's article generally explains the issue (though he's made a couple of mistakes in the article - they can be overlooked)

    And as Tom has pointed out many times in the past on AskTom, those RDBMS that do implement Boolean types for SQL, are simply defining true and false as 0 and 1 (or suchlike) in the background, so there's not much point in it.  If people are desperate to have a true/false indicator, then they could implement their own custom type (with appropriate methods for true and false) and create their columns based on that type.  Ultimately, the values are still going to take up a byte, or word etc. as there is no concept of just storing bits.

    And apologies for my previous mistake, I think it was SQL-99 when Boolean was introduced to the standards, not SQL-92.

    BluShadow wrote:
    
    If people are desperate to have a true/false indicator, then they could implement their own custom type (with appropriate methods for true and false) and create their columns based on that type.
    
    
    

    We would have to create an object type column and then change our queries from

      where t.expired = 'Y'

    to

      where t.expired.truefalse = 'TRUE'

    which I don't really see helping.

    ApexBine
  • I agree with the examples given by Sven W. and I fully agree with William Robertson.

    I'd love to be able to use boolean columns as it improves the readability of your code and it prevents mistakes as it cannot be misinterpreted.

    If you have a reason not to use it, just don't. But now, if you want to use it, you simply can't. Why should someone else (partly) decide what my design should look like?

    ApexBineMarkusHohlochuser2781259Peter Hraško
  • Dani Schnider
    Dani Schnider Member Posts: 3 Blue Ribbon

    It is TRUE (not 1 or 'T') that this feature would be very nice

    ApexBineuser2781259
  • Lukas Eder
    Lukas Eder Member Posts: 126 Bronze Badge
    edited Jul 11, 2016 10:39AM

    The nicest use case for BOOLEAN types is (as always) to perform set operations on them, like BOOL_AND() and BOOL_OR() aggregations. BOOL_AND() is the same as EVERY(). PostgreSQL has it. I've blogged about this here: [ Link to blog removed by moderator (BluShadow)  - promoting blogs is not permitted]

    Peter HraškoSentinelThorsten Kettner
  • TPD-Opitz
    TPD-Opitz Member Posts: 2,465 Silver Trophy

    The nicest use case for BOOLEAN types is (as always) to perform set operations on them, like BOOL_AND() and BOOL_OR() aggregations. BOOL_AND() is the same as EVERY(). PostgreSQL has it. I've blogged about this here: [ Link to blog removed by moderator (BluShadow)  - promoting blogs is not permitted]

    while it would be really nice to have explicit boolean analytics functions we could sumulate or() with regular max() and and() with regular min() function...

    bye

    TPD

  • Gbenga Ajakaye
    Gbenga Ajakaye Member Posts: 3,422 Gold Trophy

    Would be nice to have. Varchar NULL = 0 (no) NOT NULL = 1 (YES)?

  • TPD-Opitz
    TPD-Opitz Member Posts: 2,465 Silver Trophy

    Would be nice to have. Varchar NULL = 0 (no) NOT NULL = 1 (YES)?

    BCG14 wrote:Would be nice to have. Varchar NULL = 0 (no) NOT NULL = 1 (YES)?

    I disagree.

    That's yet another lame workaround for the missing boolean type in SQL.

    bye

    TPD