[wp-hackers] Google SoC: PostgreSQL port
Olexandr Melnyk
omelnyk at gmail.com
Fri Mar 23 11:22:53 GMT 2007
Hello,
2007/3/23, Computer Guru <computerguru at neosmart.net>:
>
> Yep, David and I are working on the port.. It's mostly done, there are
> just a couple of kinks that need sorting out here and there.
Glad to hear that the port is near completion. What especially needs to be
done? Is there a way for me to contribute to the project?
2007/3/23, Matt <speedboxer at gmail.com>:
>
> A better project would be to make WP be multi-database compatible. Maybe
> even make it more extendable so other people would be able to make there
> own
> DB ports be simply making up a file.
Agreed on this. Although I understand that's its hard to add and keep
cross-database compatibility in case
application uses some of the advanced database-specific features, it
shouldn't be the case for WordPress. Most of the MySQL-isms could be
rewritten using the standard syntax, not shortening the list of
database
features that can be used. An exception from this rule are the queries
that need to get a certain part of result rows,
what is incosistent across
databases. In MySQL, one can use both "LIMIT a, b" and "LIMIT b OFFSET
a" syntaxes. By changing queries to use the second way would add
PostgreSQL compatibility, without loosing any features. However, in
order to support other databases, some abstration function would have
to be written.
It would be nice if the common (the one that will work on PostgreSQL, but
won't stop it working on
MySQL) changes from PostgreSQL port could be applied to the main source tree.
Talking of SoC, I have another database-related idea. What I'd like to do is
to add support for sharing the same set of tables by many blogs in WordPress
MU. So far, point of view on this approach has been the main difference
between WordPress MU and Lyceum. While Lyceum developers choose to change
every query to implement this, I am suggesting to do it on database side.
That way we would get benefits of both approaches:
1) keeping the changes in WordPress source code minimal;
2) make it have a good scalability;
3) comfortable to manage, no need to run a query on each user's table
to add an extra field;
4) support WordPress plugins with no, or almost no, changes;
As a downside, I can mention that in order to implement this, triggers and
views would have to be used, thus, it would need at least MySQL 5.0 in
order to run. But, I don't think that this is a problem as most of the
blog hosting services would run on dedicated servers, where service
owners can install whatever MySQL version they prefer. And also, we
can keep this as an option, leaving the choice of approach to be used
to the end user.
What do you think?
----------------------------------------
Olexandr Melnyk
More information about the wp-hackers
mailing list