On Jun 12, 2012, at 1:29 PM, M.-A. Lemburg wrote: > > It is not really vague. For SELECT statements it refers to the number > of rows matching the query and ready to be fetched.
I'm not concerned about the SELECT case, most DBAPI's I've worked with don't support this usage (I suppose it assumes the cursor is buffering rows ? not sure) > For UPDATE, DELETE > and other statements manipulating rows it refers to the number of rows > updated, deleted or inserted. In that statement - "number of rows updated" - without the context that we on this list know what you mean, at face value it's not clear if "updated" means "matched" by the UPDATE or "actually changed with new data". Users of MySQL often have a notion of this term that is the opposite of what users of all the other database backends do. > > Whether or not rows that actually changed or all rows touched by > an UPDATE are counted is backend dependent. That was essentially my question - if "affected" is open to interpretation or if it means something specific. This says it is in fact open to interpretation. It would be nice if the spec added this phrase to the description. > > The term "affected" is a standard term used for describing the > row count. > > See e.g. the ODBC API SQLRowCount: > > http://msdn.microsoft.com/en-us/library/windows/desktop/ms711835%28v=vs.85%29.aspx I think in the vast majority of cases, nobody even debates what this term means. Only because MySQL has this odd behavior does the whole issue come into play. _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
