Passing NULL to xOpen()'s zName parameter opens a temp file. -scott
On Thu, Jul 30, 2015 at 4:29 PM, Howard Kapustein < Howard.Kapustein at microsoft.com> wrote: > >There cannot be a fully portable way, because path specifications are not > portable > Which begs the question, why isn't there an xGetTempFilename VFS function > in sqlite3_vfs? > > Wouldn't the simplify things? Have the VFS handle it apropos, with the > default VFS' in SQLite (or an older VFS lacking it) use the current hunt > sequences for compat > > - Howard > > This email may contain confidential and privileged information. Any > unauthorized use is prohibited. If you are not the intended recipient, > please contact the sender by reply email and destroy all copies of the > original message. > > -----Original Message----- > From: sqlite-users-bounces at mailinglists.sqlite.org [mailto: > sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of Simon Slavin > Sent: Tuesday, July 28, 2015 4:31 AM > To: General Discussion of SQLite Database < > sqlite-users at mailinglists.sqlite.org> > Subject: Re: [sqlite] pragma temp_store_directory is deprecated, what is > the alternative? > > > On 28 Jul 2015, at 9:55am, Paolo Bolzoni <paolo.bolzoni.brown at gmail.com> > wrote: > > > From the C interface, the way to decide the directory is setting the > > value of sqlite3_temp_directory char pointer. As explained here: > > https://www.sqlite.org/c3ref/temp_directory.html > > This is also the first place sqlite3 checks. > > The documentation is clear: > > "Applications are strongly discouraged from using this global variable. It > is required to set a temporary folder on Windows Runtime (WinRT). But for > all other platforms, it is highly recommended that applications neither > read nor write this variable. This global variable is a relic that exists > for backwards compatibility of legacy applications and should be avoided in > new projects." > > Also, sqlite3_temp_directory is accessed by the VFS level, by choice of > the VFS. You might someday switch to another VFS which ignores it. > > > From anywhere else sqlite3 checks the value of those env variables: > > SQLITE_TMPDIR, TMPDIR, TMP, TEMP, USERPROFILE. > > All uses of SQLite are 'the C interface'. That's all SQLite is: C code. > The C code checks the above places, depending on which VFS you're using, > which usually comes down to which OS you're using. > > The C code checks whatever environment variable the OS expects a user to > use to set a default location for their temporary files. (It also checks a > lot of other places, but it will definitely check whatever the > documentation for the OS says is the correct environment variable.) > Generally speaking you should let the computer's user or administrator set > this variable, since they know which drives they have attached to the > computer, and which one they want temporary files on. You're just a > programmer of one application, running on a computer you've never seen. > > The exceptions are for embedded controllers, where the programmer is the > administrator, and that on all platforms SQLite can create huge temporary > files and some systems don't have that much space available for temporary > files. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
