Hello to all, I would like to propose a new API function:
long long int sqlite3_column_rowid(sqlite3_stmt*, int iCol); As the name implies, this function would return the RowID for a given column after sqlite3_step has returned SQLITE_DATA. The RowID would be valid for the database and table name from which the field originates. Theses can already be determined by sqlite3_column_database_name, sqlite3_column_table_name and sqlite3_column_origin_name. In case no RowID is available for a field, the function should return -1 or an error value. What is the use of sqlite3_column_rowid? It is currently not possible in SQLite to determine the origin of a field value for an arbitrary select statement because its RowID is not known to the API. All other required information like database, table, and origin are already known, so this missing function would fill the gap. Who would benefit from sqlite3_column_rowid? All applications which implement updates on arbitrary select statements. Consider a software with user-define selects for which no update SQL is available in the application. With sqlite3_column_rowid, these update SQLs can easily be constructed programmatically. Wrappers, too, would benefit from sqlite3_column_rowid because it would free them from modifying SQL statements to include the RowID. Drawbacks on sqlite3_column_rowid? I can not see any negatives on sqlite3_column_rowid. I can say nothing about its implementation, but my guess is that it should not add huge loads to the library because the RowID is an integral part of most queries, but just not (yet) visible to the API. Please report your views and suggestions! Regards, Ralf
