On 06.01.2014 00:58, Simon Slavin wrote:
On 5 Jan 2014, at 6:41pm, Petite Abeille <petite.abei...@gmail.com> wrote:
On Jan 5, 2014, at 6:56 PM, Igor Tandetnik <i...@tandetnik.org> wrote:
On 1/4/2014 7:15 PM, Elrond wrote:
Short: Could you implement alter table rename column?
The problem would be, what to do with all the indexes, triggers, views and
foreign keys that reference that column?
Sure, but that’s an unrelated set of problems, isn’t it? As it stands, one
cannot even rename a column.
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.
Two alternatives: (a) actually write the parser-and-changer that processes SQL
commands, or (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.
If someone have a little time to experiment with the (a) road, it is not
so complicated as it might look at the first glance: For example sqld3
[1] is a PEG parser which, as author claims, is derived from the
SQLite's railroad syntax diagrams, which in order are derived (I
believe) from the SQLite's sources (i.e. there are chances, that the
grammar is sound).
PEG [2], is the simplest possible kind of grammar machinery, (probably
easiest for understanding for non computer language experts) - no
scanner/parser split, no ambiguity, as people often said - something
like RegExps on steroids :-).
The above project is in Ruby (is there someone who reads Ruby to give
some test results?) and it is 3 years old, but this is not so important
- I think Richard and the team are able to point out even more clever
path for pure grammar extraction in sync with the latest SQLite sources.
Once a Language grammar is available for given PEG implementation it is
usually easy to translate it for another - because the PEG rules (for
the syntax rules :-) ) are basically the same everywhere.
There are hundreds of PEG implementations already - at least several per
language. My personal favorite is one of the smallest, pure C libs -
LPeg [3], which just like the SQLite itself compiles the grammar to the
VM code. LPegLJ [4] port of [3] even does not need a C compiler (the
source code - it is JIT-ed on demand)
Parsing is the first step. I think, it would be funny if the dogfooding
principle for the second - transformation step is tried. i.e. when the
parse trees of SQlite SQL are stored back in (e.g. in memory) SQlite and
transformed there ;-).
BTW, transformation relaying on data stores are applied in one of the
modern products in that field - Rascal [5] (IMP PDB).
Another note: This topic seems somewhat related to the recent
discussions (e.g. CTEs) about SQLite RFEs which are statically
implementable (by rewriting, without changes to the SQLite engine)
Kind Regards,
Alek
[1] https://github.com/steveyen/sqld3
[2] http://en.wikipedia.org/wiki/Parsing_expression_grammar
[3] http://www.inf.puc-rio.br/~roberto/lpeg/
[4] https://github.com/sacek/LPegLJ
[5] http://www.rascal-mpl.org/
P.S. @Simon, and others closely following: Please point me to the docs
for the new style (structured) SQL objects representation in the SQlite4
- only tables? or scripts too?
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
