Re: [sqlite] unsafe use of virtual table
Ah I see now. Thank you Keith! Tom Message: 14 Date: Tue, 04 Feb 2020 14:57:06 -0700 From: "Keith Medcalf" To: "SQLite mailing list" Subject: Re: [sqlite] unsafe use of virtual table Message-ID: <62147479ae781d49902e13c3c23a3...@mail.dessus.com> Content-Type: text/plain; charset="utf-8" This is part of the trusted schema. Virtual Tables and Functions can be labeled as DIRECT_ONLY, INNOCUOUS, or unlabeled. INNOCUOUS virtual tables and functions can be used anywhere they are allowed including in the schema and views and indexes and so forth (provided that they would otherwise be permitted in that location). DIRECT_ONLY virtual tables and functions can only be used from top-level SQL, ever. Unlabeled virtual tables and views depend on whether or not the schema is trusted. If the schema containing those things (in views, the schema definitions, etc) is untrus ted, then those unlabeled virtual tables and functions are treated as DIRECT_ONLY. If the schema is trusted, then there are no restrictions on the use of unlabeled virtua l tables and functions. The TEMP schema is always trusted since it must have always been created by the application/user and cannot have been a "crafted part" of the data base. The dbstat virtual table is DIRECT_ONLY meaning that since 3.30.0 it can only be used in top-level (directly issued) SQL and not in a view, even a view created in the temp database. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] unsafe use of virtual table
Hi, I have noticed a change between 3.30 and 3.31.1 and searched for more info on "unsafe use of virtual table" on sqlite.org but could not find anything relevant. In 3.30: SQLite version 3.30.0 2019-10-04 15:03:17 Enter ".help" for usage hints. Connected to a transient in-memory database. Use ".open FILENAME" to reopen on a persistent database. sqlite> create view somestats as select name, pgoffset from dbstat; sqlite> select * from somestats; sqlite_master|0 But in 3.31.1: SQLite version 3.31.1 2020-01-27 19:55:54 Enter ".help" for usage hints. Connected to a transient in-memory database. Use ".open FILENAME" to reopen on a persistent database. sqlite> create view somestats as select name, pgoffset from dbstat; sqlite> select * from somestats; Error: unsafe use of virtual table "dbstat" Could someone point me to where I can find more info on unsafe use of virtual tables? Thanks Tom ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Release date of 3.30.1
Hi, The Release date of SQLite 3.30.1 is listed on your website as 2019-10-11, but the SQLite shell, as well as the SQLITE_SOURCE_ID constant, say it is 2019-10-10 20:19:45. Is this a typo on your website? https://sqlite.org/index.html https://sqlite.org/chronology.html SQLite version 3.30.1 2019-10-10 20:19:45 Enter ".help" for usage hints. Connected to a transient in-memory database. Use ".open FILENAME" to reopen on a persistent database. I checked a few other versions down to 3.25.3, and they all had the expected release date. Version 3.25.3 was tagged in Fossil at 2018-11-05 20:37, but still lists its release date as 2018-11-05. Thanks Tom ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] SQLITE_USE_ALLOCA compile time option on FreeBSD
Hi, Looking through the recommended compile-time options at: https://sqlite.org/compile.html It recommends using SQLITE_USE_ALLOCA on systems that support it. On macOS and FreeBSD, the man page for alloca says something like this: BUGS The alloca() function is machine and compiler dependent; its use is discouraged. The alloca() function is slightly unsafe because it cannot ensure that the pointer returned points to a valid and usable block of memory. The allocation made may exceed the bounds of the stack, or even go further into other objects in memory, and alloca() cannot determine such an error. Avoid alloca() with large unbounded allocations. FreeBSD 12.0-RELEASE-p9September 5, 2006 FreeBSD 12.0-RELEASE-p9 Not a big deal, just a little confusing for alloca() to be recommended yet discouraged by OS. Tom ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Documentation correction
Hi, I just wanted to point out a minor discrepancy in the docs below. https://www.sqlite.org/lang_createtable.html#rowid where it says: If a table contains a user defined column named "rowid", "oid" or "_rowid_", then that name always refers the explicitly declared column and cannot be used to retrieve the integer rowid value. Shouldn't it say at the end "unless that user defined column is an alias for the rowid." For example, you can retrieve the integer rowid value from a user defined column named "rowid" if it defined as the integer primary key: CREATE TABLE t(rowid integer primary key); insert into t values(15); select rowid, oid from t; Results: 15|15 Thanks, Tom ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] WITHOUT ROWID tables with a ROWID
Ah I see now. Sorry I should have read the docs more carefully -- it is working according to spec in all cases. Great answers. Thanks guys! Tom ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
