Donnacha,
> You're quite right, they HAVE heavily optimized their application to
> handle MySQL's foibles, they don't use an abstraction layer, a PgSQL
> edition of vB would involve a major rewrite, I don't know why inserts
> are a particularly huge issue for them but I will ask them to clarify
> their position.
My personal conjecture:
The "extended insert" is not on the Postgres TODO list because:
a) It's not ANSI SQL standard.
b) We have COPY, which is better.
So given their raising that ridiculously small point, as well as their
flippant answer on MySQL licensing, I don't think the arguments they are
advancing are real. They are excuses for not switching to *anything* else,
because the vbulletin developers don't know, and don't want to learn,
anything new, and *certainly* don't want to re-write their whole application
to utilize an abstraction layer. I would bet you that the folks advocating
Oracle will meet with a similar stonewall.
Which is their perogative, it's their application. The reason I bring this
up with you is that I'd rather not see *you* beat your head against a wall.
From my perspective, this situation sounds exactly like that of Compiere,
where the project leads have found excuses for 4 years not to work on
compatibility with other databases. In PostgreSQL's case, it was lack of
nested transactions.
--
Josh Berkus
Aglio Database Solutions
San Francisco
