[wp-hackers] PostgreSQL port status?

[Jacob]

Thanks.

Probably should find the files that has mysql_* in them and change them 
over to use the $wpdb instead. I'm dealing with something else at this 
moment. As I have no need for this, I'm going to leave it to you and the 
others.

Looking forward to the conclusion.

Jacob Santos

Computer Guru wrote:
> OK, ATM WordPress is already *technically* is extendable by sticking db.php in \wp-content\
>
> I've attached a db.php w/ the replaced MySQL functions, but unfortunately, WordPress doesn't honor its own system and has mysql_* functions hard-coded into other files.
>
> Queries hard-coded into files I can understand, but there is absolutely no need to ever call mysql_* functions outside of wp-db.php.... everything else should use that class.
>
> Right, so no guarantees or anything - I'm using the code from the file forwarded by usleepless for the conversion.... I have to go right now, but assuming you can get wp-setup to use $wpdb instead of its own hard-coded mysql functions (shouldn't be too hard) it should work to some minimal extent :)
>
> Computer Guru
> NeoSmart Technologies
> http://neosmart.net/
>
>
>   
>> -----Original Message-----
>> From: wp-hackers-bounces at lists.automattic.com [mailto:wp-hackers-
>> bounces at lists.automattic.com] On Behalf Of Jacob
>> Sent: Monday, October 01, 2007 6:29 AM
>> To: wp-hackers at lists.automattic.com
>> Subject: Re: [wp-hackers] PostgreSQL port status?
>>
>> Perhaps, you are right. However, we wouldn't know, unless the the core
>> devs join this discussion, which seems unlikely since it would appear
>> like the dozen others before it.
>>
>> In my opinion, I would have liked to have used SQLite and had an easy
>> way to do it. However, the thought of having to do find and replace
>> lowers my motivation to even attempt it.
>>
>> Which ever method might work, I however won't even attempt it if it is
>> required that I do the find and replace method. I would with my method.
>> The devs wouldn't have to support any other DB other than MySQL, so
>> they'll be allowed to use any MySQL SQL and table scheme they want.
>> This
>> solution would allow for those who want to support other Databases to
>> do
>> so without forking and give an easy but time consuming way to do so.
>>
>> Both methods would require a lot of work for the plugin or fork author.
>> Mine would require some up front core changes, which would be a lot of
>> work in itself. I think the only issue I would have, is if the core
>> team
>> would accept such a patch that would do so many changes? I think with
>> the prepare stuff, right now isn't the best time, unless there already
>> existed a patch. Any patch at this moment would be worthless since it
>> wouldn't be able to be applied without conflicts.
>>
>> This isn't an issue that I'm concerned with, so I'll bow out from
>> voting
>> on the issue. I'm just offering a possible solution.
>>
>> Jacob Santos
>>
>> Jared Bangs wrote:
>>     
>>> On 9/30/07, Matt <speedboxer at gmail.com> wrote:
>>>
>>>       
>>>> There's nothing wrong with WP supporting multiple DBs, but doing so
>>>>         
>> in a way
>>     
>>>> that doesn't interfere with anything is the problem...
>>>>
>>>>
>>>>         
>>> Yeah, I would think that if a drop in replacement for the wp-db file
>>> could do the trick (although it would probably not be optimal), it
>>> might be useful to add a hook at the point of $wpdb assignment, to
>>> facilitate overrides by plugins rather than having to replace and/or
>>> modify the core files.
>>>
>>> I also imagine that there would have to be some performance trade-
>>>       
>> offs
>>     
>>> with doing it that way; specifically involving potentially rewriting
>>> every query (with regex, etc.) before it's executed.
>>>
>>> Support on an "equal" level would probably be more complicated, as it
>>> should involve replacing (or at least adding specific replacement
>>> hooks for) any vendor specific SQL throughout the app.
>>>
>>> The latter might be quite the undertaking, but I could see the value
>>> in it. It would be especially useful to already have in place if the
>>> situation ever came up where PGSQL (or any other DB) releases a new
>>> version that breaks all speed records and becomes the clear choice
>>>       
>> for
>>     
>>> performance, etc.
>>>
>>> Whether that (and portability in general) is enough to justify all
>>>       
>> the
>>     
>>> work required to get there is a matter that lots of people would
>>> probably have strong opinions on, on both sides of the issue.
>>>
>>> For me, it comes down to two things: (1) cost / benefit analysis (are
>>> the potential gains worth the extra effort), and (2) would these
>>>       
>> types
>>     
>>> of changes (to the core code to better facilitate portability) be in
>>> line with the vision of the core devs.
>>>
>>> The second will greatly impact the first. I'd be interested in
>>>       
>> helping
>>     
>>> out with the changes just for the fun of it, but if the consensus is
>>> that we don't want to go there (in core), it probably wouldn't be
>>> worthwhile to prepare all the patches, etc.
>>>
>>> - Jared
>>> _______________________________________________
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>>
>>>       
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>     
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>