Hi Jeremy Thank you for implementing that functionality so quickly!
I gave it a try and it worked perfect with Postgres 8.4 and extra option ":return => :primary_key". Great! Now, without this option, where I used to get back nil, I get now an array containing sql queries that were just executed. Not sure if this is intentional, and it is certainly confusing. Also, I personally do not quite agree with decision to degrade multi_insert to insert_multiple if user asked to get back primary keys and database does not support it. It does not satisfy the 'principle of least surprise' and most likely would create a problem that can go unnoticed for quite some time. I would rather have Sequel throw an exception if code asked for a feature that can not be provided by a database. If you do not want to throw an exception here (there are some reasons not to like it), then maybe always returning list of ids for databases where this is possible, and nil for databases where it is not possible, may be a better, more reliable approach. What do you think? On Dec 12, 7:41 pm, Jeremy Evans <[email protected]> wrote: > > I decided to implement > this:https://github.com/jeremyevans/sequel/commit/4003876b987e44969335dac1... > > Please give the master branch a shot and let me know if it works out. > > Thanks, > Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
