> But just > wondering, was allowing to create such field intentional? As I suppose such > field is complete phantom since most sql queries will interpret rowid > internally and won't allow access this user field at all.
Situation is completely opposite. When you declare your field named "rowid" the real rowid becomes phantom and all queries will select your field instead. But real rowid will be still accessible via other names like "_rowid_" or "oid" (is there a way to access real rowid when all three built-in names are declared by user in the table, I wonder?). And this behavior is documented (see http://www.sqlite.org/lang_createtable.html) and thus I suppose intended and introduced long ago. Pavel On Wed, May 26, 2010 at 10:13 AM, Max Vlasov <max.vla...@gmail.com> wrote: > While implementing a table that intended for arbitrary table storage, I > automatically named some field rowid not linking at the moment that it will > have a name conflict with sqlite internal rowid name. Lately I discovered > this, and (not a big deal) recreated table with a different name. But just > wondering, was allowing to create such field intentional? As I suppose such > field is complete phantom since most sql queries will interpret rowid > internally and won't allow access this user field at all. > > Max > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
