This is funny...

This is funny...

Your belief that RETURNING doesn't work in Oracle is untrue. It does (though you have to RETURNING a .nextval, indeed), and is the recommended approach rather than using .currval, because it saves a roundtrip to the database.

Of course “RETURNING” works, but... how exactly will it save the roundtrip? When you use “nextval”/“currval” idiom you can just batch all your operation in one statement using “BEGIN”/“END” - thus using one single roudtrip. How exactly last_insert_id emulation can beat this is mystery to me.

Sure, sometimes you want to do some manipulations in your application before continuing - and in this case it's natural to use last_insert_id with MySQL (but not with Oracle).

Writing an abstraction layer which abstracts over all SQL differences is of course over the top... but abstracting over trivial, always-needed stuff like 'what is the sequence number of the row I just inserted' is, well, trivial.

Actually it's not trivial. In MySQL LAST_INSERT_ID only gives you one number but in Postresql or Oracle you can generate few different numbers. And since one roundtrip can include quite a few elemental operations it's not easy or simple to transform one to another.

I've written such an abstraction layer myself more than once, and that was a little one-man thing, and it was not very much effort.

WOW! Cool.

How exactly have you processed Oracle's “insert” statements which used two distinct sequences in MySQL?

That PHP couldn't do it says volumes.

About your unreasonable expectations? Sure. About SQL driver? Not much. DBI example which produces suboptimal results does not expire confidence: I'd rather handle such problems at the application level rather then in intense debugging session which will show that that my perfectly tuned code on some other database uses “insert” over unindexed table "because driver had no other choice". Thnks... but no, thnks.