On 8 Dec 2010, at 8:03pm, Bogdan Ureche wrote: > Now that foreign key constraints are enforced natively, why would you want > >> to have a list of them? Why should the foreign_key_list pragma continue to >> consume code space and developer maintenance time? > > It would make life easier for developers of administration tools for SQLite, > for displaying/editing foreign key constraints visually. The alternative > would be to parse the CREATE TABLE statements.
Just like Jan, I have a system that populates blank forms based on the default values for columns and provides popup lists based on FOREIGN KEYs. I would find it useful to be able to retrieve all elements of the database schema, up to and including which TRIGGERs exist. I don't know that the 'foreign_key_list' is the best way to do it, but I would like /a/ way to do it. Perhaps expanding 'PRAGMA table_info' by creating a second parameter for that could be 'tables', 'columns', 'indexes', 'triggers', 'foreign keys', etc. would be a good way to go. Ideally it should be possible to completely reproduce the schema from columns, so I don't have to write a text parser for sqlite_master. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
