[sqlite] [feature request] Quirk-fixing compile-time options

Hi, I was very happy to see the addition of the SQLITE_DQS compile-time option, which fixes one of the legacy bugs/quirks of SQLite3. I was wondering if additional compile-time options could be added to fix two other legacy quirks: - Primary Keys containing NULLs

Re: [sqlite] Feature request: more robust handling of invalid UTF-16 data

*Richard:* the issue with the JSON extension seems unrelated to the issue that I reported originally, which relates to the SQLite C API (specifically, the sqlite3_bind_text16() and sqlite3_bind_text16() functions). My issue is still not fixed. I've expanded my original sample code to make it

Re: [sqlite] Feature request: more robust handling of invalid UTF-16 data

On 1/14/20, Richard Hipp wrote: > I'm having trouble reproducing this. I went back to version 3.30.1 and I was able to reproduce it. So I bisected and found the following: https://sqlite.org/src/timeline?c=51027f08c0478f1b -- D. Richard Hipp d...@sqlite.org

Re: [sqlite] Feature request: more robust handling of invalid UTF-16 data

On 1/13/20, Dennis Snell wrote: > We have a JSON document like this which we store in a table. > > {“content”: “\ud83c\udd70\ud83c(null)\udd71”,”tags":[]} > > > The JSON is well-formed but the sequence of UTF-16 code points is invalid. > > When sqlite reads this data two types of further

Re: [sqlite] Feature request: more robust handling of invalid UTF-16 data

Betreff: Re: [sqlite] Feature request: more robust handling of invalid UTF-16 data I’d like to raise this issue again and give my support for what Maks Verver recommended in  https://www.mail-archive.com/sqlite-users@mailinglists.sqlite.org/msg110107.html Independently I came to this bug while

Re: [sqlite] Feature request: more robust handling of invalid UTF-16 data

I’d like to raise this issue again and give my support for what Maks Verver recommended in  https://www.mail-archive.com/sqlite-users@mailinglists.sqlite.org/msg110107.html Independently I came to this bug while working on an issue in Simplenote’s Android app where our data was being corrupted

Re: [sqlite] Feature request: (VALUES (1), (2), (3)) AS t(n)

(Hopefully this works.) > How about something like: > > with t(a, b) as (values (1, 1), (2, 2)) select a, b from t; Yeah, CTEs are an obvious alternative. I mostly request this AS t(n) feature because I have had some otherwise-portable PostgreSQL queries that I needed to tweak for SQLite. The

Re: [sqlite] Feature request: (VALUES (1), (2), (3)) AS t(n)

pov >Sent: Thursday, 7 November, 2019 13:44 >To: sqlite-users@mailinglists.sqlite.org >Subject: [sqlite] Feature request: (VALUES (1), (2), (3)) AS t(n) > >Good day! It's my first time writing to a mail list for a very long >time, so I may not get this right the first time. > >I

[sqlite] Feature request: (VALUES (1), (2), (3)) AS t(n)

Good day! It's my first time writing to a mail list for a very long time, so I may not get this right the first time. I would like to request the ability to write: SELECT * FROM (VALUES (1, 1), (2, 2)) AS t(a, b) ; Instead of: SELECT t.column1 AS a, t.column2 AS b FROM (VALUES

Re: [sqlite] Feature request: import MySQL dumps in CLI

On 7 Aug 2019, at 9:16pm, Thomas Kurz wrote: > Well, that's why I asked for an *import* support. It's widely spread practice > to offer at least import capabilities from other software. This is what the .import function in SQLite's shell tool is for. It reads a well-documented text format.

Re: [sqlite] Feature request: import MySQL dumps in CLI

Wednesday, August 07, 2019, 9:16:17 PM, Thomas Kurz wrote: >> I highly doubt the SQLite team will undertake this task. They >> Surely have the skill to do so, but their priority is the one >> software product you desire to use, undoubtedly due to its >> high utility. I doubt that utility would

Re: [sqlite] Feature request: import MySQL dumps in CLI

> I highly doubt the SQLite team will undertake this task. They > Surely have the skill to do so, but their priority is the one > software product you desire to use, undoubtedly due to its > high utility. I doubt that utility would exist if they were > to wander off tacking the conversion

[sqlite] Feature request: import MySQL dumps in CLI

Mr. Kurz writes: > I suppose I am not the only one having to convert between > MySQL/MariaDB and SQLite databases every now and then. I > know there are converters for MySQL dumps but none of any > I have ever tried did work nearly reliable. If you dislike the available converters and do not wish

Re: [sqlite] Feature request: import MySQL dumps in CLI

The BIGGEST problem I had with importing data from MySQL to SQLite is the table definitions. If you do two dumps, one specifically for table definitions, the other for the actual data to be imported, you could get a script to handle the table definition file to make it conform to what SQLite can

Re: [sqlite] Feature request: import MySQL dumps in CLI

archar(50) not null END TRANSACTION; - Original Message - From: Simon Slavin To: SQLite mailing list Sent: Wednesday, August 7, 2019, 18:25:45 Subject: [sqlite] Feature request: import MySQL dumps in CLI On 7 Aug 2019, at 5:13pm, Thomas Kurz wrote: > So my suggestion would

Re: [sqlite] Feature request: import MySQL dumps in CLI

On 7 Aug 2019, at 5:13pm, Thomas Kurz wrote: > So my suggestion would be to add an import feature to the CLI that allows to > directly import MySQL/MariaDB dumps into an SQLite database keeping as many > information as possible. As SQLite already has a complete SQL parser I expect > much

[sqlite] Feature request: import MySQL dumps in CLI

Dear SQLite team, I suppose I am not the only one having to convert between MySQL/MariaDB and SQLite databases every now and then. I know there are converters for MySQL dumps but none of any I have ever tried did work nearly reliable. So my suggestion would be to add an import feature to the

Re: [sqlite] feature request -- enhance strftime() implementing %V, %g and %G for week of year according to ISO 8601

lf Of Luuk Sent: Thursday, May 9, 2019 7:57 PM To: sqlite-users@mailinglists.sqlite.org Subject: Re: [sqlite] feature request -- enhance strftime() implementing %V, %g and %G for week of year according to ISO 8601 On 9-5-2019 18:20, Nißl Reinhard wrote: > Hi, > > it would be nice, if

Re: [sqlite] Feature request, sqlite3_stmt_action

Working with RediSQL another use case comes to mind for some implementation of the interface we were discussing. How to detect SELECT statements that return empty. SQLite simply return SQLITE_DONE in all cases, and it makes impossible to know if it is an empty SELECT or something else. A

Re: [sqlite] feature request -- enhance strftime() implementing %V, %g and %G for week of year according to ISO 8601

On 9-5-2019 18:20, Nißl Reinhard wrote: Hi, it would be nice, if sqlite3's strftime() would support the following formatting codes: %g The last 2 digits of the ISO 8601 week-based year as a decimal number (00 - 99) %G The ISO 8601 week-based year as a decimal number %V ISO

[sqlite] feature request -- enhance strftime() implementing %V, %g and %G for week of year according to ISO 8601

Hi, it would be nice, if sqlite3's strftime() would support the following formatting codes: %g The last 2 digits of the ISO 8601 week-based year as a decimal number (00 - 99) %G The ISO 8601 week-based year as a decimal number %V ISO 8601 week number as a decimal number (00 - 53)

Re: [sqlite] Feature request: FILTER on aggregate functions

On 5/6/2019 5:19 PM, Shawn Wagner wrote: I just found out that postgres (And possibly others?) supports FILTER on aggregate functions in general, not just when they're used as a window function. Trivial example: SELECT count(*), count(*) FILTER (WHERE amount > 100) FROM blah which is a

[sqlite] Feature request: FILTER on aggregate functions

I just found out that postgres (And possibly others?) supports FILTER on aggregate functions in general, not just when they're used as a window function. Trivial example: SELECT count(*), count(*) FILTER (WHERE amount > 100) FROM blah which is a lot cleaner than SELECT count(*),

[sqlite] Feature request: ALTER TABLE ... ADD CONSTRAINT...

Hi! I don't know if this has been already discussed, most probably yes. But are there any plans to implement the possibility to add constraints to existing tables? And I'm not necessarily asking for full-blown functionality. Currently to do that you have to drop the table and recreate it again

Re: [sqlite] Feature request, sqlite3_stmt_action

On 28 Mar 2019, at 10:25am, Dominique Devienne wrote: > Some info about the statement from EXPLAIN QUERY PLAN, that DRH would agree > to, and accept to "publicly document" and thus support would be nice, You want something like EXPLAIN EFFECTS OF and it should answer with zero or more

Re: [sqlite] Feature request: dynamically referenced bind parameters

Oooo this is really neat. Thanks! > On Mar 27, 2019, at 5:12 PM, Richard Hipp wrote: > > See https://www.sqlite.org/carray.html > > -- > D. Richard Hipp > d...@sqlite.org > ___ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org >

Re: [sqlite] Feature request, sqlite3_stmt_action

On Thu, Mar 28, 2019 at 10:59 AM R Smith wrote: > Maybe even, if possible, This query updates these tables: x1, x2, x3... > etc. (some of which might hide behind an FK relation or Trigger) but I > know this is pushing my luck. :) > What I ended-up doing is introspecting the VDBE program of

Re: [sqlite] Feature request, sqlite3_stmt_action

On 2019/03/28 9:07 AM, Olivier Mascia wrote: Le 27 mars 2019 à 18:04, siscia a écrit : I would like to propose a function (named `sqlite3_stmt_action` for the sake of discussion) that allow to understand if a specific statement is either a SELECT, UPDATE, DELETE or INSERT. There is probably a

Re: [sqlite] Feature request, sqlite3_stmt_action

On Thu 28 Mar 2019 at 08:07, Olivier Mascia wrote: > > > Le 27 mars 2019 à 18:04, siscia a écrit : > > > > I would like to propose a function (named `sqlite3_stmt_action` for the > sake > > of discussion) that allow to understand if a specific statement is > either a > > SELECT, UPDATE, DELETE

Re: [sqlite] Feature request, sqlite3_stmt_action

> Le 27 mars 2019 à 18:04, siscia a écrit : > > I would like to propose a function (named `sqlite3_stmt_action` for the sake > of discussion) that allow to understand if a specific statement is either a > SELECT, UPDATE, DELETE or INSERT. There is probably a much more complex need that I did

Re: [sqlite] Feature request: dynamically referenced bind parameters

See https://www.sqlite.org/carray.html -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature request: dynamically referenced bind parameters

t: Wednesday, 27 March, 2019 14:22 >> To: SQLite mailing list >> Subject: [sqlite] Feature request: dynamically referenced bind >> parameters >> >> I’ve commonly encountered cases where I have a many-to-many >> relationship, and I would like to retrieve those relationsh

Re: [sqlite] Feature request: dynamically referenced bind parameters

nly a Stairway to Heaven says a lot about anticipated traffic volume. >-Original Message- >From: sqlite-users [mailto:sqlite-users- >boun...@mailinglists.sqlite.org] On Behalf Of Joshua Thomas Wise >Sent: Wednesday, 27 March, 2019 14:22 >To: SQLite mailing list >Subj

[sqlite] Feature request: dynamically referenced bind parameters

I’ve commonly encountered cases where I have a many-to-many relationship, and I would like to retrieve those relationships in a single query. For example: CREATE TABLE staff ( email TEXT PRIMARY KEY, name TEXT ); CREATE TABLE articles ( id INTEGER PRIMARY KEY, title TEXT, body TEXT,

Re: [sqlite] Feature request, sqlite3_stmt_action

e reported? -Original Message- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of siscia Sent: Wednesday, March 27, 2019 1:05 PM To: sqlite-users@mailinglists.sqlite.org Subject: [sqlite] Feature request, sqlite3_stmt_action Hi List, I would like

[sqlite] Feature request, sqlite3_stmt_action

Hi List, I would like to propose a feature and I believe here is the best place. Please keep in mind that I am ready to work on a patch for this feature if needed, but I would like to discuss it here first. I would like to propose a function (named `sqlite3_stmt_action` for the sake of

[sqlite] Feature request: ARM64 support in Universal Windows Platform

Hi, Microsoft released few days ago Visual Studio 2017 release 15.9 that brings full support for building Universal Windows Platform apps targeting new ARM64 platform. https://blogs.windows.com/buildingapps/2018/11/15/official-support-for-windows-10-on-arm-development SQLite library is already

[sqlite] Feature request: degenerates in Lemon's report

Hello, Could you allow an outputting of autoreduced states when they produce conflicts? I have noticed that such errors are caused by small and hard-to-find remnants in a grammar file. There is no other way to detect such errors. A few lines are getting the problem off (function

[sqlite] Feature request: A function to read the value of db->u1.isInterrupted

Feature request: A function to read the value of db->u1.isInterrupted The purpose of this is so that extensions that implement additional SQL functions and/or virtual tables that use loops that aren't VDBE programs can still know that it is interrupted. For example, if the extension uses libcurl

[sqlite] Feature request: more robust handling of invalid UTF-16 data

*Background: *UTF-16 is an encoding which allows most characters to be encoded in a single 16-bit code unit. Characters outside the basic multilingual plane (i.e. code points between 0x1 and 0x10), require two code units: a high surrogate between 0xD800 and 0xDBFF, followed by a low

Re: [sqlite] feature request: MIN() and MAX() of set of row values

On 13/04/18 14:12, Simon Slavin wrote: On 13 Apr 2018, at 8:40am, Mark Brand wrote: It also occurs to me that COUNT() should work (but doesn't) over sets of row values: sqlite> select count((1,2)); Error: row value misused I would expect it to return the

Re: [sqlite] feature request: MIN() and MAX() of set of row values

On 13 Apr 2018, at 8:40am, Mark Brand wrote: > It also occurs to me that COUNT() should work (but doesn't) over sets of row > values: > > sqlite> select count((1,2)); > Error: row value misused > > I would expect it to return the number of non-NULL row values in

Re: [sqlite] feature request: MIN() and MAX() of set of row values

On 13/04/18 09:32, Mark Brand wrote: On 30/03/18 18:55, Igor Tandetnik wrote: Row values support less-than comparison, so it kind of makes sense to expect MIN to work on them, too. That's what I was thinking too. One would expect aggregate MIN() and MAX() to work over row values. While

Re: [sqlite] feature request: MIN() and MAX() of set of row values

On 30/03/18 18:55, Igor Tandetnik wrote: Row values support less-than comparison, so it kind of makes sense to expect MIN to work on them, too. That's what I was thinking too. One would expect aggregate MIN() and MAX() to work over row values. While we're on the subject of row values,

Re: [sqlite] Feature request for the Shell Tool: .mode json

On Sun, 21 Jan 2018 05:54:13 + Simon Slavin escribió: > Feature request for the Shell Tool: ".mode json". > Others has pointed to libraries to export to json, so I point to the one I use: libucl https://github.com/vstakhov/libucl Using the generation functions [1]

Re: [sqlite] Feature request for the Shell Tool: .mode json

On Mon, Jan 22, 2018 at 12:50 AM, Stadin, Benjamin < benjamin.sta...@heidelberg-mobil.com> wrote: > wrote a tool to convert an arbitrary SQLite result set to properly typed > json key/value pairs, using the SQLite type affinity of the objects. > ... > while ((rc = sqlite3_step(readStmt)) ==

Re: [sqlite] Feature request for the Shell Tool: .mode json

>Just the data returned by the SELECT command, expressed as an array of objects, one object per row. That's what shell_callback() does inside shell.c. It outputs one row at a time in the current mode selected by the cases of a big switch() statement. Not sure I follow how your code would be

Re: [sqlite] Feature request for the Shell Tool: .mode json

On Sun, Jan 21, 2018 at 3:50 PM, Stadin, Benjamin < benjamin.sta...@heidelberg-mobil.com> wrote: > Hi Simon, > > I recently wrote a tool to convert an arbitrary SQLite result set to > properly typed json key/value pairs, using the SQLite type affinity of the > objects. Though the code is in C++.

Re: [sqlite] Feature request for the Shell Tool: .mode json

Hi Simon, I recently wrote a tool to convert an arbitrary SQLite result set to properly typed json key/value pairs, using the SQLite type affinity of the objects. Though the code is in C++. But it gives an idea how simple this is when with a JSON library (I'm using RapidJson). Rapidjson can

Re: [sqlite] Feature request for the Shell Tool: .mode json

On Sun 21 Jan 2018 4:21 PM, Simon Slavin wrote: > > > On 21 Jan 2018, at 3:05pm, Brian Curley wrote: > > > pipe it > > through jq instead. > > I did not know jq existed. Thanks. Just gave the documentation a quick > glance. > You might like to see some code examples:

Re: [sqlite] Feature request for the Shell Tool: .mode json

On 21 Jan 2018, at 11:01pm, Simon Slavin wrote: > Just the data that is stored in the table, expressed as a JSON object, not an > array. Sorry, what I meant was Just the data returned by the SELECT command, expressed as an array of objects, one object per row. Simon.

Re: [sqlite] Feature request for the Shell Tool: .mode json

On 21 Jan 2018, at 9:22pm, petern wrote: > Simon. You want something like MySQL but using SQLite's shallower column > type awareness? Reference: > > https://dev.mysql.com/doc/refman/5.7/en/mysql-shell-json-output.html Just the data that is stored in the table,

Re: [sqlite] Feature request for the Shell Tool: .mode json

Simon. You want something like MySQL but using SQLite's shallower column type awareness? Reference: https://dev.mysql.com/doc/refman/5.7/en/mysql-shell-json-output.html Would you include a header variable when headers are turned on? Column types too? There are a number of design choices to

Re: [sqlite] Feature request for the Shell Tool: .mode json

On 21 Jan 2018, at 6:56pm, Brian Curley wrote: > In short, yes...you can get jq to convert both ways. > > It's not exactly as simple as just piping it through jq though, just to > reiterate my earlier self-correction. Hi, Brian. Thanks for your detailed example which I

Re: [sqlite] Feature request for the Shell Tool: .mode json

hi, Simon. In short, yes...you can get jq to convert both ways. It's not exactly as simple as just piping it through jq though, just to reiterate my earlier self-correction. JSON is intended to allow rich data definition, such that there's no quick fix that would suit all parties; in my own

Re: [sqlite] Feature request for the Shell Tool: .mode json

On 21-01-18 17:15, Brian Curley wrote: > Well, I did oversimplify to just say 'pipe it through', but it's really > more like a sed usage. > > You wouldn't see much difference if you'd pipe your delimited output > through sed or awk either, unless you threw in some directives, or a > script. It

Re: [sqlite] Feature request for the Shell Tool: .mode json

On 21 Jan 2018, at 3:05pm, Brian Curley wrote: > pipe it > through jq instead. I did not know jq existed. Thanks. Just gave the documentation a quick glance. jq is not installed on my platform (macOS) whereas sqlite3 is. Does jq do conversion both ways ? Can jq deduce

Re: [sqlite] Feature request for the Shell Tool: .mode json

Well, I did oversimplify to just say 'pipe it through', but it's really more like a sed usage. You wouldn't see much difference if you'd pipe your delimited output through sed or awk either, unless you threw in some directives, or a script. It would require some planning on the part of the user,

Re: [sqlite] Feature request for the Shell Tool: .mode json

On 21-01-18 16:05, Brian Curley wrote: > Is there even a need to embed it into sqlite itself? Since you're on the > shell, and in keeping with the whole 'do one thing well' mandate: pipe it > through jq instead. > > Beautiful creature that jq... > > Regards. > > Brian P Curley > >

Re: [sqlite] Feature request for the Shell Tool: .mode json

Is there even a need to embed it into sqlite itself? Since you're on the shell, and in keeping with the whole 'do one thing well' mandate: pipe it through jq instead. Beautiful creature that jq... Regards. Brian P Curley On Jan 21, 2018 9:54 AM, "J Decker" wrote: > On

Re: [sqlite] Feature request for the Shell Tool: .mode json

On Sat, Jan 20, 2018 at 9:54 PM, Simon Slavin wrote: > Feature request for the Shell Tool: ".mode json". > > Output should be as a JSON array of objects, with one object for each row > of the table. Output should start with the "[" character and end with > "]". Rows

[sqlite] Feature request for the Shell Tool: .mode json

Feature request for the Shell Tool: ".mode json". Output should be as a JSON array of objects, with one object for each row of the table. Output should start with the "[" character and end with "]". Rows should be separated with ",\n". Quotes in strings should be escaped for JSON, with a

Re: [sqlite] Feature request: merge joins (preferably through a hint)

On 7 Nov 2017, at 7:59am, Davor Josipovic wrote: > What sqlite does now is for each "a" it searches through the index for "x". If an ideal index already exists, accessing the correct records will be fast. If one does not exist, how would you expect a merge join to be any

Re: [sqlite] Feature request: merge joins (preferably through a hint)

> You are thinking that perhaps queries such as the following might > be faster using a merge: > > SELECT * FROM tab1 JOIN tab2 ON tab1.a=tab2.x; > > I disagree. I don't see any reason to disagree. Merge join will definitely be faster if the data is already sorted. See the reference:

Re: [sqlite] Feature request: merge joins (preferably through a hint)

On 5 Nov 2017, at 11:04am, Richard Hipp wrote: > SQLite does do a merge in some cases, though not for what you would > traditionally call a join. For example, SQLite will do a merge to > combine the two halves of this query: > >SELECT a,b,c FROM tab1 UNION SELECT x,y,z

Re: [sqlite] Feature request: merge joins (preferably through a hint)

On 11/5/17, Davor Josipovic wrote: > Merge joins could be an incredible optimization in some cases for large > queries and would make sqlite much faster in such cases. SQLite does do a merge in some cases, though not for what you would traditionally call a join. For example,

[sqlite] Feature request: merge joins (preferably through a hint)

Are there any plans to implement merge joins in sqlite? As far as I am aware, only nested loops are currently supported. Merge joins could be an incredible optimization in some cases for large queries and would make sqlite much faster in such cases. Personally, I would like to have this option

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

On Fri, Aug 04, 2017 at 10:55:57AM -0500, Bob Friesenhahn wrote: > Sqlite does not really have a way to know if a module in the current > directory (the directory which just happened to be current when the request > was made) should be trusted. To be secure, sqlite should insist that the > load

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

On Fri, Aug 04, 2017 at 08:20:10AM -0700, J Decker wrote: > On Fri, Aug 4, 2017 at 8:11 AM, Nico Williams wrote: > > No, see, the ".so"/".dll" suffix is used in all cases, and it varies by > > platform, so it's best if SQLite3 adds it so you can keep your code more > >

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

On Fri, 4 Aug 2017, Peter Da Silva wrote: On 8/4/17, 8:29 AM, "sqlite-users on behalf of Bob Friesenhahn" wrote: Lazy programmers who request such things are of the same ilk which use programming

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

On Fri, Aug 4, 2017 at 8:11 AM, Nico Williams wrote: > On Fri, Aug 04, 2017 at 10:17:33AM +0200, Dominique Devienne wrote: > > On Fri, Aug 4, 2017 at 2:46 AM, Nico Williams > wrote: > > > You're mistaken. > > > > > > lib.so is NOT "the default

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

On Fri, Aug 4, 2017 at 6:29 AM, Bob Friesenhahn < bfrie...@simple.dallas.tx.us> wrote: > On Fri, 4 Aug 2017, Dominique Devienne wrote: > >> >> I really don't see what's controversial with Matt's request :) >> >> It's not like load-extension is a performance-critical operation, that >> trying an

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

On Fri, Aug 04, 2017 at 10:17:33AM +0200, Dominique Devienne wrote: > On Fri, Aug 4, 2017 at 2:46 AM, Nico Williams wrote: > > You're mistaken. > > > > lib.so is NOT "the default naming scheme on many *nix platforms". > > > > lib.so is the naming scheme when you want the

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

On Fri, Aug 04, 2017 at 06:05:53AM +, Hick Gunter wrote: > >Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im > >Auftrag von Nico Williams > >But loadable modules are almost never meant to be used that way. > >They're usually meant to be used only through dlopen() and

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

On 8/4/17, 8:29 AM, "sqlite-users on behalf of Bob Friesenhahn" wrote: > Lazy programmers who request such things are of the same ilk which use > programming practices resulting in SQL injection attacks.

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

On Fri, 4 Aug 2017, Dominique Devienne wrote: I really don't see what's controversial with Matt's request :) It's not like load-extension is a performance-critical operation, that trying an extra load is that expensive. And the security consideration that an "attacker" could make it load his

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

On Fri, Aug 4, 2017 at 2:46 AM, Nico Williams wrote: > On Tue, Aug 01, 2017 at 10:56:47AM -0700, Matt Chambers wrote: > > load_extension() has the very sensible behavior of: > > > So for example, if "samplelib" cannot be loaded, then names like > > > "samplelib.so" or

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

>Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im >Auftrag von Nico Williams > >On Tue, Aug 01, 2017 at 10:56:47AM -0700, Matt Chambers wrote: >> load_extension() has the very sensible behavior of: >> > So for example, if "samplelib" cannot be loaded, then names like >>

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

On Tue, Aug 01, 2017 at 10:56:47AM -0700, Matt Chambers wrote: > load_extension() has the very sensible behavior of: > > So for example, if "samplelib" cannot be loaded, then names like > > "samplelib.so" or "samplelib.dylib" or "samplelib.dll" might be tried > > also. > > I would like to see

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

On Thu, Aug 3, 2017 at 10:42 AM, Bob Friesenhahn < bfrie...@simple.dallas.tx.us> wrote: > On Tue, 1 Aug 2017, Matt Chambers wrote: > > load_extension() has the very sensible behavior of: >> >>> So for example, if "samplelib" cannot be loaded, then names like >>> "samplelib.so" or

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

On Tue, 1 Aug 2017, Matt Chambers wrote: load_extension() has the very sensible behavior of: So for example, if "samplelib" cannot be loaded, then names like "samplelib.so" or "samplelib.dylib" or "samplelib.dll" might be tried also. I would like to see that extended to include

[sqlite] Feature request: check for 'lib' prefix for load_extension()

load_extension() has the very sensible behavior of: > So for example, if "samplelib" cannot be loaded, then names like > "samplelib.so" or "samplelib.dylib" or "samplelib.dll" might be tried > also. I would like to see that extended to include "libsamplelib.so" since that is the default naming

Re: [sqlite] Feature request: support for FROM_UNIXTIME

On 6/13/2017 11:21 AM, René Cannaò wrote: I would like to have support for FROM_UNIXTIME() function, as available in MySQL: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_from-unixtime Some background about this feature request. ProxySQL

[sqlite] Feature request: support for FROM_UNIXTIME

I would like to have support for FROM_UNIXTIME() function, as available in MySQL: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_from-unixtime Some background about this feature request. I perfectly understand that SQLite is not MySQL, that FROM_UNIXTIME is a

[sqlite] Feature request: please have the sqlite3_set_authorizer callback given the full list of tables and columns used by a statement

Hello, I'm the author of GRDB.swift [1], a Swift wrapper around SQLite which aims, among other things, at notifying of transactions that may have an impact on a the results of a SELECT statement. For example, `SELECT a, b FROM table1` is impacted by `DELETE FROM table1`, but not by `UPDATE

Re: [sqlite] Feature request

On 1/16/17, Simon Slavin wrote: > > > I think it would be easy to add but I’m not part of the dev group and don’t > really know if this is the case. > The implementation is here: https://www.sqlite.org/src/artifact/dc3f1391d9297f8c?ln=983-1133 Who can send me a patch? --

Re: [sqlite] Feature request

On 16 Jan 2017, at 1:10pm, Stephen Chrzanowski wrote: > From the above link: > > %V is replaced by the week number of the year (Monday as the first day of > the week) as a decimal number [01,53]. If the week containing 1 January has > four or more days in the new year,

Re: [sqlite] Feature request

-- Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im Auftrag von Simon Slavin Gesendet: Montag, 16. Jänner 2017 13:30 An: SQLite mailing list <sqlite-users@mailinglists.sqlite.org> Betreff: Re: [sqlite] Feature request On 16 Jan 2017, at 12:17pm, Hick Gunter <h...@

Re: [sqlite] Feature request

Straight up, I've never had to concern myself with the week number of a year. I'm aware of it, but, with it a moving number year to year, I've never relied on it, or even had the requirement/desire to output it as a result, except maybe for 'fun'. The SQLite.org page references that strftime

Re: [sqlite] Feature request

On 16 Jan 2017, at 12:17pm, Hick Gunter wrote: > Please be aware that %V implies %G/%g (four and two digit ISO Year number), > which differs from %Y/%y on the "spillover days" that belong to the > first/last week of the "other" year. Can you tell me where your %G and %g

Re: [sqlite] Feature request

lists.sqlite.org] Im Auftrag von Simon Slavin Gesendet: Montag, 16. Jänner 2017 11:44 An: SQLite mailing list <sqlite-users@mailinglists.sqlite.org> Betreff: Re: [sqlite] Feature request On 16 Jan 2017, at 7:53am, Jean-Christophe Deschamps <j...@antichoc.net> wrote: > Would it be possib

Re: [sqlite] Feature request

On 16 Jan 2017, at 7:53am, Jean-Christophe Deschamps wrote: > Would it be possible to add the '%V' format (ISO week number in [01..53]) in > some future release? For those playing along at home, the EU week starts on a Monday, with week 1 being the one which contains the

[sqlite] Feature request

Dear list, I often have to use SQLite strftime() to compute a week number but the only proposed format '%W' causes problems. Not only that north-american week number has a varying range [00..52] or [01..53] but some years (e.g. 2012, 2040) yield a result in [00..53], making those years 54

[sqlite] Feature request: ANALYZE REMOVE

I would like a version of the ANALYZE command which drops all the tables that ANALYZE creates, then updates the query planner so that it knows no stats are available. This command is intended to help with A) automated testing and time-trials B) cleanup for transporting datasets from one setup

[sqlite] Feature Request: Support for MMAP beyond 2GB

On Fri, 30 Oct 2015 12:01:15 -0700 Roger Binns wrote: > https://sqlite.org/mmap.html > > SQLite supports memory mapping databases, but only does so for the > first 2GB of the file. My databases are around 4 to 20GB, and > completely fit within RAM on my 64 bit systems. The 2GB mmap limit >

[sqlite] Feature Request: Support for MMAP beyond 2GB

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 https://sqlite.org/mmap.html SQLite supports memory mapping databases, but only does so for the first 2GB of the file. My databases are around 4 to 20GB, and completely fit within RAM on my 64 bit systems. The 2GB mmap limit means that only a

[sqlite] Feature request for sqlite3_initialize().

On Sat, Sep 5, 2015 at 6:42 PM, Darin Adler wrote: > Michael is planning a workaround in WebKit that will call > sqlite3_initialize manually exactly once before WebKit uses sqlite, using > std::once to deal with the thread safety issue. > This reminds me ... I was recently working on a patch

Re: [sqlite] Feature Request - RowCount

> > On 14 Dec 2014, at 11:08am, Jean-Christophe Deschamps > wrote: > > > Without using slow triggers or changing the v3 file format there is still > > another possibility which could be implemented relatively easily. All it > > would need is a new pragma (or internal

Re: [sqlite] Feature Request - RowCount

On 2014/12/13 21:46, James K. Lowden wrote: So the number of tools with feature X is no measure of the value of X. (Notable example: the tool should keep every query and result in a time-sequenced transcript log, so that prior results can be re-examined and prior queries modified. Most tools

Re: [sqlite] Feature Request - RowCount

Jim Callahan wrote:>#26 The unique columns have non-null values (the answer says a lot more,>but that is the essence of what I am relying on). Right, but the question was how to count rows as quickly as possible regarding any or all columnse.g. count(ProspectName) from Clients;  One can imagine

  1   2   3   4   >