[database] [Database] Toward better databases

[Larry Garfield]

On Tue, 08 Jul 2008 11:24:14 -0700, "Joshua D. Drake" <jd at commandprompt.com> wrote:

>> 3.  Larry isn't going to like this, but part of the reason I haven't
>> mustered the time to finish the pgsql driver is that I am not 100%
>> convinced the design for the PDO-based database layer is right yet,
>> and figuring out a proposal to fix it requires more time than I've had.
>>
> 
> I am not against PDO but is there a reason we didn't just include a
> light and generic wrapper on top of the old fashion functions? Isn't
> that what PDO is? (note: not much of a php guy here).

The generic wrapper around the old fashioned functions is what we have in Drupal 6 and earlier, and it is very very limiting.  PDO is not just a wrapper around those.  It is a single userspace interface with swappable C-level drivers for each supported backend, so that the userspace code is the same either way.  (At least that's the goal; Sadly it doesn't abstract out things like funky blob handling, which is where the problem comes in.)

>> 3a.  One issue is that the way that SQL and placeholders are generated
>> seems fragile and inefficient to me.  It ends up being fairly awkward
>> for the pgsql driver to keep everything straight in the way it needs
>> to in order to do its most basic function of calling bindParam()
>> correctly (though it is much better than in early drafts of the patch).
>>
> 
> Remind me, are we doing client side or server side prepare?

We're relying on PDO for the prepare.  In MySQL, emulating them in PDO rather than letting MySQL do them is faster, as MySQL's prepared statements bypass the query cache for some bizarre reason.  In Postgres, I think we're letting Postgres do it.

--Larry Garfield