On Wed, 22 Mar 2017 15:07:41 +0000
Simon Slavin <slav...@bigfraud.org> wrote:
> On 22 Mar 2017, at 11:52am, R Smith <rsm...@rsweb.co.za> wrote:
> >
> > May I add further that views are tricky things. They can refer to
> > multiple tables, or other views which in turn refer to multiple
> > tables or yet other views (and have obscured the names of the
> > original tables via "AS" aliasing). There is no way to easily
> > implement an automatic view-of-table dropper. (I've tried to do
> > something like this for an sqlite tool long ago).
>
> I think I?ve tried to do the equivalent thing for TRIGGERs and also
> failed. And there?s also FOREIGN KEYs, though you can figure those
> out using PRAGMA calls.
It's only "tricky" because SQL is tricky to parse. Given a parser,
collecting terminal nodes of a particuar type is simple.
An interesting -- and innovative -- SQLite function would expose the
parser's result as ordinary data:
sqlite3_parse_sql( sqlite3*, const char sql[] )
returning two tables representing the parse tree, along the lines of
Expressions:
expression_id
parent_expression_id
table_name
column_number
column_name
column_type
column_size
and
Operations:
operation_id
left_expression_id
left_expression_column_number
right_expression_id
right_expression_column_number
That's just off the top of my head. Doubtless the experience of
representing JSON trees as tables would provide insight, too.
--jkl
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
