Re: 0/1 vs true/false - Mailing list pgsql-general

From Andrew Ayers
Subject Re: 0/1 vs true/false
Date
Msg-id 3F200CAB.8020703@eldocomp.com
Whole thread Raw
In response to 0/1 vs true/false  (Jean-Christian Imbeault <jc@mega-bucks.co.jp>)
List pgsql-general
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
informationthat is privileged, confidential and exempt from disclosure under applicable law. If you are not the
intendedaddressee, 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
thismessage in error, please immediately advise the sender by reply email, and delete the message. Thank you. 

pgsql-general by date:

Previous
From: Andrew Ayers
Date:
Subject: Re: Limited varchar, unlimited varchar, or text?
Next
From: "scott.marlowe"
Date:
Subject: Re: Postgres unique index checking and atomic transactions