Hi, On Sun, Jan 05, 2014 at 22:58:31 +0000, Simon Slavin wrote: [...] > You're both right. Igor's statement pretty-much /is/ the > reason one cannot rename a column. One would need to > write a parser and changer for SQL statements that could > identify and change column names in many statements with > all sorts of weird possibilities for formatting.
Isn't most of the parser already existant, because sqlite must parse the in-db-schema-sql to know the structure of the database? And there already must be code to identify column names in the parsed structure, for exactly the above named reasons (checking constraints, checking foreign keys)? Obviously, the parser is not a parser-and-changer. Agreed. What about this simple solution: Let "alter table rename column" parse the schema, search for the column name. If it's in no constraint, etc, then do the rename in the sqlite_master table. If the column is used anywhere, error out (which is not worse than before). This will at least stop people from creating databases, that can't be opened after mangling around in the sqlite_master table. As originally stated, my aim is not a full blown alter table implementation right away, but only renaming (possibly unreferenced) columns. > Two alternatives: (a) actually write the > parser-and-changer that processes SQL commands, or For creating the actual changer, one might use the already parsed in-memory-structure, change it, and dump it back out as sql. That might break formatting for people who love it, but that's still lots better than doing nothing. Being able to dump the internal structures as sql might also be helpful for debugging and writing test cases. > (b) wait until the major file format changes in SQLite4, > then change the way SQL stores the CREATE commands needed > to construct a database so it stores a structured version > of the commands instead of the raw text. The "structured version" could be the dumped-sql from above? But of course, sqlite4 could use some fancy structured format for that as well. But why invent a new (binary) format, when we have a text based format at hand, that can do everything needed? > The advantage of either change would be that it allows > almost all the ALTER TABLE commands SQL users expect, not > just changing column names. If that's true, that would be great! > This simplifies life not just for normal users but also > for all the writers of SQLite GUI managers out there, Simplifying the world for everyone would be awesome. Like the foreignkeys are awesome. Instead of everybody having to create (possibly wrong) triggers, those triggers are now builtin. > who have to write nasty risky time-consuming hacks if > they want to accomplish those operations. I am especially afraid of the risky part. That's not the reliable attribute sqlite is known for. That's why my suggestion from above is to start with simple operations, and if sqlite can't do them reliably (because it would break something), then error out. That would even improve the gui managers: They could try the sqlite internal variant (reliable), then ask the user "Okay, the reliable method did not work, I have some fallback methods, which are not as reliable, but used to work most of the time. Should I apply those?" > Simon. Cheers Elrond _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
