I'm going to state right up front that I have very little experience with sqlite and, if I can help demonstrate that this ticket is valid, I will.
That said, it comes as no surprise that I had never looked at sqlite_master before. So, I checked out the contents and found that, with my very simple test database, there is only one *_autoindex_* and that was on the table which has a BLOB for the primary key. All tables that had integer primary keys did not have any such index. I'm not sure why an autoindex would be expected on a table for which a physical integer column was declared to be the primary key. As for detecting the column which has the primary key, that is not a typical functionality provided by a database subsystem. Contraints exist to maintain consistency and are typically not queryable (at least not in my experience). Maybe this is typically queryable and I've just never had a need that exposed me to it. My uninformed guess is that the autoindex that you would see when putting a UNIQUE constraint on the second column is on the second column for more efficient constraint checking. Again, I don't really know how the autoindex is used or anything so I may be full of it. On Mon, 28 Nov 2005, Bogdan Ureche wrote: > Will, > > Thanks for the reply. Yes, the table gets created, however the primary key > (sqlite_autoindex_tablename_1) if it is created, is not visible as a > distinct row in sqlite_master. > > Are you saying that the index is created even if it is not added to > sqlite_master? If the answer is yes, then how could one find the primary key > for a table (preferably without parsing sqlite_master.SQL)? > > Regards, > > Bogdan >
