On Fri, Jul 27, 2018 at 11:33 AM R Smith <ryansmit...@gmail.com> wrote:
> On 2018/07/27 10:40 AM, Dominique Devienne wrote: > > On Fri, Jul 27, 2018 at 1:58 AM Richard Hipp <d...@sqlite.org> wrote: > >> On 7/26/18, Tomasz Kot <tom...@gmail.com> wrote: > >>> Beneath sql shall throw an error on CREATE VIEW statement (as invalid > >>> column is specified), but it passes (SQLite 3.23.1). > >> The error is deferred until you try to use the view. The reason for > >> deferring the error is that the problem might be corrected by > >> subsequent DDL statements prior to using the view. > >> > > Would it be possible to have a pragma that easily detects all invalid > views? > > Does an existing one already do that? That would be useful IMHO. > > I'm sure it is possible, though you will probably receive the usual > "code bloat avoidance" reply (which I tend to agree with). > Sigh. We already have 4 different check pragmas (cell-size, fk, integrity, quick). One more for views seems perfectly in line with those. Did anyone raise the same old light-code-bloat argument for those too, in the past? I for one cringe every time I read it nowadays. In any case, it's always entirely at the discretion of DRH, and although he of course considers the communities views (pun intended) I'm sure, at the end of the day he's the sole decider. > That said, it's easy to do in a bit of code which you can add to your > libraries as a standard function, which will go something like this (in > pseudo): > Of course it is. But many many people use SQLite entirely via sqlite3[.exe] with no C code extensions of their own. > Which you can spruce up by adding the actual sqlite error return code or > description. > You can also UNION in the sqlite_temp_master to check temporary views if > needed. > Some pragmas AFAIK, are already DB aware and can restrict themselves to a given attached DB. > One caution, some views that have ordered sub-selects linked to very > large tables (or other stuff I don't know about) might take a long time > to even simply prepare - so perhaps not a good idea to automatically add > this after every script. > Really? I've never heard that preparing a statement depended on how large tables accessed are. Doesn't prepare only ever cares about data dictionaries (i.e. DDL stuff) and not actual rows (DML stuff)? Preparing is not only running the SQL parser and generating the VDBE program for that statement? If what you wrote was true, wouldn't that imply the result of prepare could be different depending if the prepare happens with a empty or "full" table? Or I completely misunderstood your "large table" comment? Thanks, --DD _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
