Re: [GENERAL] 0/1 vs true/false
Greg Stark wrote: > Instead I have to have =='f' and =='t' strewn throughout my code everywhere > making it harder to read and extremely fragile. If I forget one anywhere I > silently get subtly broken semantics. Why did you do that? Why not create a single function (isTrue()?) that you pass the field through and let the function evaluate it. It doesn't solve the issue, but it would make your code more stable, and if things ever changed (ie, from a "t" to a "1" or something) - you just update that one function. In fact (and my C/C++ memory is hazy) - you should be able to create a set of functions or methods in you code/classes that could take a variety of data types as the passed type, and have each of those funnel down to one type to evaluate and pass up the chain - so you could call the function isTrue(int) or isTrue(char *) or something, and it would always work OK (ie, a polymorphic function/method). That way, your code could always call the *same* function/method, and always know it was going to return the same value - but behind the scenes, it would be doing all the "funky exercises" needed to return the proper value. If it ever radically changes (or you change the DB), you change one function, and the system keeps working (no having to hunt and change 'n' lines of code). Yes, there would be a little more overhead - but future maintenance coders (or yourself, down the line) will thank you for your "foresight". Andrew L. Ayers Phoenix, Arizona -- CONFIDENTIALITY NOTICE -- This message is intended for the sole use of the individual and entity to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email, and delete the message. Thank you. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] 0/1 vs true/false
and what about boolean attirbutes in where clauses? Is any difference between -SELECT ... WHERE boolean_field and -SELECT ... WHERE boolean_field=true ? On Wed, 2003-07-23 at 11:48, Tom Lane wrote: Franco Bruno Borghesi <[EMAIL PROTECTED]> writes: > This makes me wonder, what about 't' and 'f'?... will they disappear in > newer versions of postgreSQL? No. See my comment about I/O representations being outside the spec. There is no inconsistency in the following examples: regression=# select true; bool -- t (1 row) regression=# select t; ERROR: attribute "t" not found regression=# select 't'::boolean; bool -- t (1 row) regression=# select '1'::boolean; bool -- t (1 row) regards, tom lane signature.asc Description: This is a digitally signed message part
Re: [GENERAL] 0/1 vs true/false
(B (B (B (BI have looked around, but not found the standard. Where I have looked, (Bit seems to be: (B (B t/f, (B . not (B true/flase (B 0/1 (B yes/no (B (BJean-Christian Imbeault wrote: (B (B Nigel J. Andrews wrote: (B (B (BI had do do this sort of thing for a some developers. It was actually 'true' (Band 'false' that was wanted not the 0/1. I wrote a little plgsql function and (Binstalled it as a cast to text. (B (B (B (BThanks. I know that there are workarounds, I just want to "prove" that (B0/1 is not standards compliant. If I can do that I am pretty sure that (Bthe developer will have nothing against changing to true/false. (B (BRight not he just things postgresql must be broken because 0/1 works in (BMySQL ... But he's pretty good when it comes to fixing things because (Bthey don't follow standards. So if I can show him his SQL isn't (Bstandards compliant he'll probably happily fix it. (B (BJean-Christian Imbeault (B (B (B---(end of broadcast)--- (BTIP 3: if posting/reading through Usenet, please send an appropriate (B subscribe-nomail command to [EMAIL PROTECTED] so that your (B message can get through to the mailing list cleanly (B (B (B (B (B (B (B
Re: [GENERAL] 0/1 vs true/false
On Wed, 23 Jul 2003, Tom Lane wrote: > "scott.marlowe" <[EMAIL PROTECTED]> writes: > > On Wed, 23 Jul 2003, Tom Lane wrote: > >> Well, there is no boolean type per se in SQL92. But there is in SQL99. > > > Was it pulled from SQL92 before it went standard? My copy of the > > pre-release lists a boolean type, just like the 99 standard does. > > Where? SQL92 says nothing about a declarable boolean datatype that > I can see. They're a bit schizophrenic in that they do define a lot > of operators that are described as returning boolean ... but you cannot > create a column of type boolean, nor is there a boolean-literal construct. > AFAICS, boolean values can only exist "in flight" between operators and > a WHERE or HAVING clause in SQL92. Yep, you're right. I was looking at how they treated booles in search conditions, and figured they had a type to match. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] 0/1 vs true/false
"scott.marlowe" <[EMAIL PROTECTED]> writes: > On Wed, 23 Jul 2003, Tom Lane wrote: >> Well, there is no boolean type per se in SQL92. But there is in SQL99. > Was it pulled from SQL92 before it went standard? My copy of the > pre-release lists a boolean type, just like the 99 standard does. Where? SQL92 says nothing about a declarable boolean datatype that I can see. They're a bit schizophrenic in that they do define a lot of operators that are described as returning boolean ... but you cannot create a column of type boolean, nor is there a boolean-literal construct. AFAICS, boolean values can only exist "in flight" between operators and a WHERE or HAVING clause in SQL92. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] 0/1 vs true/false
On Wed, 23 Jul 2003, Tom Lane wrote: > Jean-Christian Imbeault <[EMAIL PROTECTED]> writes: > > Oops, I meant to say can someone point me to a ressource (SQL standard > > and section?) which states that true/false must be used for booleans :) > > Well, there is no boolean type per se in SQL92. But there is in SQL99. > I think the most relevant part of the spec is the definition of boolean > literals in section 5.3: > > ::= > TRUE > | FALSE > | UNKNOWN Was it pulled from SQL92 before it went standard? My copy of the pre-release lists a boolean type, just like the 99 standard does. further, intermediate SQL compliance has this in it: 24)Subclause 8.12, "": a) A shall not specify a . Does that mean you should only use the "is true" suntax, not the =true? ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
