Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40966
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error)
Cc: PHP internals <internals@lists.php.net>
Message-ID: <E6844AB1-E105-4D6A-845F-0AA4E3CDA000@pooteeweet.org>
To: Lester Caine <lester@lsces.co.uk>
In-Reply-To: <48F42AFA.3020908@lsces.co.uk>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Tue, 14 Oct 2008 07:48:56 +0200
References: <48EBA7E4.7060305@lsces.co.uk>	 <5E0F8553-2F2C-448D-936D-B39517F661BF@pooteeweet.org>	 <48F3D13F.70801@iamjochem.com> <fe05d1540810131613rbe6911dh3aeef78a80af0b1c@mail.gmail.com> <48F42AFA.3020908@lsces.co.uk>
Subject: Re: [PHP-DEV] php_firebird
From: mls@pooteeweet.org (Lukas Kahwe Smith)


On 14.10.2008, at 07:15, Lester Caine wrote:

> Pierre Joye wrote:
>>> effectively the extension for firebird already exists ... it just  
>>> maps to the interbase
>>> function, if the fbird_*() aliases were removed and renamed copies  
>>> the ibase_*()
>>> extensions functions created that then were built against the  
>>> firebird client iso
>>> the interbase client you'd pretty much be there. technically the  
>>> [firebird] extension
>>> would be new but is that really a deal breaker given that the  
>>> complete API (fbird_*())
>>> already exists?
>> I do not understand this paragraph.
>
> When Ard rebuilt the php_interbase driver for PHP5 he created fbird_  
> aliases for all the ibase_ functions. The driver is specific to PHP5  
> and always has been. It was never back ported to PHP4. The PLAN was  
> always when there was a pressing need to separate Interbase and  
> Firebird all of us who use fbird_ would simply switch to  
> php_firebird without any internal code changes. At present there is  
> a 'niggle' rather than a 'pressing need' to implement the split, but  
> given the other discussions going on, now is probably the time to  
> sort this out as well?
>
> I have no problem with php_interbase and php_firebird being in pecl,  
> as long as they are being compiled somewhere for those of us who do  
> not have M$ tools but have to support customers who have yet to  
> convert to Linux ;)


Ok, I was not aware of this. It does change things a bit, but imho I  
would still prefer if most of this could be handled by an extension  
internal switch. As for the use case of using interbase and firebird  
in parallel. If you absolutely need this and are unwilling to do this  
inside a PDO driver I do acknowledge that there are a lot of features  
missing from the current PDO driver, the performance difference does  
not strike me as a valid argument though. Foremost its not like its a  
difference of day and night, also fetchAll() can actually increase  
performance compared to the current database extensions. Also its  
still negible compared to the time applications spend on their  
queries. Also its not like PDO cannot be improved (of course there are  
some limits in the current architecture).

So for core my opinion holds, that only PDO drivers should be added,  
but PECL is of course another story.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org