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)

How about something like: with t(a, b) as (values (1, 1), (2, 2)) select a, b from t; -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-Original Message- >From: sqlite-users On >Behalf Of Ainar Garipov >Sent:

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

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

You can use the SQL files from OpenGeoDB as an example: http://www.fa-technik.adfc.de/code/opengeodb/opengeodb-begin.sql The result (see below) from the https://github.com/dumblob/mysql2sqlite converter is completely useless as none of the create statements is complete. I have observed severe

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

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

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

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

Yes, but the problem is that I need to also retrieve the articles themselves. If I were to embed the articles query inside the staff query (as you’ve shown), the database would have to execute the article query twice. > On Mar 27, 2019, at 4:42 PM, Keith Medcalf wrote: > > > You mean

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

You mean something like this: SELECT staff.* FROM staff, contributions WHERE contributions.staff = staff.email AND contributions.article IN (SELECT id FROM articles WHERE publish_date <= CURRENT_TIMESTAMP ORDER BY publish_date DESC LIMIT ?); --- The fact that there's a Highway to Hell but only

Re: [sqlite] Feature request, sqlite3_stmt_action

I'm not familiar with the C API, but the question I'll ask is this: How should this work with triggers? Running a statement as simple as "delete from foo;" could result in any number of different updates, deletes or inserts from any number of different tables, so how should that be reported?

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

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,

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

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

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

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

Re: [sqlite] Feature Request - RowCount

Hi Simon, A) In that sqlite_sequence table you mentioned, as an additional column. Always up-to-date. But sqlite_sequence isn't always created. AFAIK it only exists when one or more table exists with an integer primary key autoincrement. B) In the tables prepared by SQLite ANALYZE. If

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 function) like

Re: [sqlite] Feature Request - RowCount

At 03:14 14/12/2014, you wrote: ´¯¯¯ I take the point that the only possible improvements seem to need alteration to the file structure or added maintenance which may use up cycles for something that just isn't that important to DB use in general - and I have to agree, I too have zero want for

Re: [sqlite] Feature Request - RowCount

On 2014/12/13 14:38, Richard Hipp wrote: The "SELECT count(*) FROM table" query already has a special optimization in the b-tree layer to make it go faster. You can see this by comparing the times of these queries: SELECT count(*) FROM table; SELECT count(*) FROM table WHERE 1;

Re: [sqlite] Feature Request - RowCount

> On 14/12/2014, at 4:17 am, Simon Slavin wrote: > > > On 13 Dec 2014, at 12:38pm, Richard Hipp wrote: > >> Also, if there are indices available, SQLite attempts to count the smallest >> index (it has to guess at which is the smallest by looking at the

Re: [sqlite] Feature Request - RowCount

On 13 Dec 2014, at 7:46pm, James K. Lowden wrote: > Every DB Admin tool I've ever used proved to be more hinderance than > help. They seem to be written by the moderately competent to help the > novice, and run out of gas or fall over when faced with anything >

Re: [sqlite] Feature Request - RowCount

On Sat, 13 Dec 2014 14:15:15 +0200 RSmith wrote: > Most DB Admin tools out there displays the number of rows in a table > when you select it or open it, so too the one I am working on and > after testing stuff on Simon's question about the row counting, I > realised that

Re: [sqlite] Feature Request - RowCount

No. The fastest is to do "count(*)". -- D. Richard Hipp Sent from phone - Excuse brevity On Dec 13, 2014 11:13 AM, "Jim Callahan" wrote: > So, if I understand the discussion the fastest way to get a count from the > command line interface (CLI) is to count the

Re: [sqlite] Feature Request - RowCount

So, if I understand the discussion the fastest way to get a count from the command line interface (CLI) is to count the rows in the primary key, assuming you have a primary key and that it is not a composite key. SELECT COUNT(primarykey) FROM table1 The "primarykey" in the above example is a

Re: [sqlite] Feature Request - RowCount

On 13 Dec 2014, at 12:38pm, Richard Hipp wrote: > Also, if there are indices available, SQLite attempts to count the smallest > index (it has to guess at which is the smallest by looking at the number > and declared datatypes of the columns) and counting the smallest index >

Re: [sqlite] Feature Request - RowCount

The "SELECT count(*) FROM table" query already has a special optimization in the b-tree layer to make it go faster. You can see this by comparing the times of these queries: SELECT count(*) FROM table; SELECT count(*) FROM table WHERE 1; The WHERE clause on the second query disables

Re: [sqlite] feature request: aliasing (or renaming) db (not table) names

On Thu, Jul 24, 2014 at 4:51 PM, Stephan Beal wrote: > [stephan@host:~/cvs/fossil/libfossil/src]$ f-query -e "select * from > ckout.vfile limit 1" -S > BTW: the -S option has historically meant "SQL Tracing," but i think i'll rename it to "Simon" now ;). i've been

Re: [sqlite] feature request: aliasing (or renaming) db (not table) names

On Thu, Jul 24, 2014 at 4:45 PM, Simon Slavin wrote: > > On 24 Jul 2014, at 3:38pm, Stephan Beal wrote: > > > THANK YOU! > > You're welcome. I'm still learning more from this list than I'm putting > out. > Hope we never meet, because i will likely

Re: [sqlite] feature request: aliasing (or renaming) db (not table) names

On 24 Jul 2014, at 3:38pm, Stephan Beal wrote: > THANK YOU! You're welcome. I'm still learning more from this list than I'm putting out. Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org

Re: [sqlite] feature request: aliasing (or renaming) db (not table) names

On Thu, Jul 24, 2014 at 4:10 PM, Simon Slavin wrote: > > On 24 Jul 2014, at 3:07pm, Stephan Beal wrote: > > > A simpler solution which would serve my goals just as well: the ability > to > > rename only 'main' (e.g. sqlite3_rename_db(sqlite3*, char

Re: [sqlite] feature request: aliasing (or renaming) db (not table) names

On 24 Jul 2014, at 3:07pm, Stephan Beal wrote: > A simpler solution which would serve my goals just as well: the ability to > rename only 'main' (e.g. sqlite3_rename_db(sqlite3*, char const * > newName)). i don't need 'main' because main is fluid in these apps. i need > a

Re: [sqlite] feature request: aliasing (or renaming) db (not table) names

On Thu, Jul 24, 2014 at 4:02 PM, Simon Slavin wrote: > Really ? It would dramatically simplify your programming and not take up > much space. Oh well. > It's not the space, but the "pile of files" debate which has raged for years in SCMs. Fossil already has its one

Re: [sqlite] feature request: aliasing (or renaming) db (not table) names

On 24 Jul 2014, at 2:52pm, Stephan Beal wrote: > note that i can't justify using a file for this purpose, because that file > has to live somewhere, and the only reasonable place for it is in the > checkout directory. It would clutter the source trees. Really ? It would

Re: [sqlite] feature request: aliasing (or renaming) db (not table) names

On Thu, Jul 24, 2014 at 3:51 PM, Stephan Beal wrote: > i did in fact try that (way back in the beginning), using a :memory: db as > my main db. > note that i can't justify using a file for this purpose, because that file has to live somewhere, and the only reasonable

Re: [sqlite] feature request: aliasing (or renaming) db (not table) names

On Thu, Jul 24, 2014 at 3:18 PM, Simon Slavin wrote: > Create a fourth database with no content. That's always the main one. > Everything else is always attached to it. > i did in fact try that (way back in the beginning), using a :memory: db as my main db. However, the

Re: [sqlite] feature request: aliasing (or renaming) db (not table) names

On 24 Jul 2014, at 2:11pm, Stephan Beal wrote: > The problem is, an application does not > (cannot) necessarily know which order the dbs were opened, so it doesn't > really know if "main" is the repo db, the checkout db, or the config db. Create a fourth database with no

Re: [sqlite] Feature request - Tcl variables as "value-list"s

Thread necromancy! Back in 2007 I expressed a desire to efficiently insert a *list* of values all at once, where the entire list is contained within a single Tcl variable. The notation would be to use the variable name, prefixed with $ or :, in place of the value list, intentionally omitting

Re: [sqlite] Feature request: Better support for database file moving

On 12 Nov 2013 at 16:14, Stephen Chrzanowski wrote: > **kind of off topic** > > @Tim> I'm no where near in thinking that it should be SOP. > > I'm somewhat appreciative of not being allowed to change the "file > containers" visual representation a file while something has

  1   2   3   >