Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:13794
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
In-Reply-To: <20041107220011.GA7261@panix.com>
References: <30EB6453-305B-11D9-80C2-000A95C705DC@chittenden.org> <EOEIIEMPJGBOGHFJBKAFOEGLCBAA.michaels@crye-leike.com> <20041107220011.GA7261@panix.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-ID: <9C51B9C2-31B4-11D9-8EBB-000A95C705DC@chittenden.org>
Content-Transfer-Encoding: 7bit
Cc: PHP Internals List <internals@lists.php.net>
Date: Mon, 8 Nov 2004 10:32:57 -0800
To: Daniel Convissor <danielc@analysisandsolutions.com>
Subject: Re: [PHP-DEV] PostgreSQL driver handles boolean values incorrectly...
From: sean@chittenden.org (Sean Chittenden)

>>> A boolean value is returned as the strings 't' and 'f', not the
>>> constants true and false.  This presents all kinds of interesting
>>> oddities for code that does something like:
>
> I suspect that behavior has nothing to do with PHP and everything to
> do with PostgreSQL.  Each DBMS outputs their information in their own
> way.
>
> Now, should PHP implement a new standard to convert that into a
> standard format, well that's another question.  The answer is "no."
> That would cause compatibility problems.

Bah, provide a backwards compatibility config option.  As the following 
poster suggests, PHP needs some way of advancing itself out of the 
stone age as a programming language.  The use of php.ini for register 
globals sets a precedent to allow this to happen, IMHO.  Something 
like: pgsql_bool_return_string = true for the near future, then change 
over to pgsql_bool_return_string = false at some later date.  My other 
cohorts on this contract had the exact same idea and to me it seems 
more than rather plausible to me.

>> You're probably already aware of this, but you can use a bit(1)
>> field as a boolean
>
> Most DBMS's don't support BIT column types.  Second, some of those
> that do don't allow NULL in them.  NULL is a legit value for a BOOLEAN
> column.

NULL can be a legit value for any column depending on the DDL.  NULL 
can also be an invalid value for any particular column.  I don't see 
how this makes any difference.

-sc

-- 
Sean Chittenden