On Thu, 4 Jul 2013 20:36:10 +0100
Simon Slavin wrote:
> On 4 Jul 2013, at 8:15pm, James K. Lowden
> wrote:
>
> > It doesn't usually matter, right? The fact that the atomic SELECT
> > is spread out across N function calls is irrelevant if they are
> > ex
On Thu, 04 Jul 2013 16:08:38 -0400
Igor Tandetnik wrote:
> On 7/4/2013 3:15 PM, James K. Lowden wrote:
> > This weird case is one of (I would say) misusing the connection.
> > IMO SQLite should return an error if prepare is issued on a
> > connection for which a pre
On Fri, 05 Jul 2013 12:38:37 +0200
Gabriel Corneanu wrote:
> About complexity: I'm not sure it's NlogN; for each N you need to
> count N-1 columns, that's N^2 IMO.
You're right if the data aren't sorted.
If the data are sorted, to *find* the largest value smaller than a given
value is O(log N
On Fri, 05 Jul 2013 02:19:08 +0200
Olaf Schmidt wrote:
> Create Table T (ID Integer Primary Key, Item Text)
>
> Select Count(Lesser.ID), T.ID, T.Item From T As T
> Left Outer Join T As Lesser
> On T.ID > Lesser.ID
> Group By T.ID
> Order By T.ID
>
> I don't know,
On Mon, 08 Jul 2013 00:37:55 -0400
Igor Tandetnik wrote:
> I don't believe it's SQLite's job to ensure the programmer doesn't
> shoot herself in the foot. After all, you don't expect, say, the C++
> compiler to prevent you from destroying an object while another part
> of the program holds a poin
On Mon, 8 Jul 2013 15:32:21 -0400
"peter korinis" wrote:
> . a CLAIMS table = 43M rows with indices on claim_no and
> stateCounty code; and
>
> . a LINE table = 85M rows with indices on claim_no and HCPCS
> (a 5 char text code)
>
> . Have run ANALYZE
>
> . Usin
On Fri, 12 Jul 2013 16:02:37 -0400
Richard Hipp wrote:
> On Fri, Jul 12, 2013 at 3:01 PM, Igor Tandetnik
> wrote:
>
> > On 7/12/2013 12:30 PM, James K. Lowden wrote:
> >
> >> The documented behavior is - if you modify the data as you iterate
> >>
On Fri, 12 Jul 2013 14:25:36 -0400
Igor Tandetnik wrote:
> >it is very much SQLite's job to prevent logical
> > programming errors from corrupting the data.
>
> Define "the data". The database file remains perfectly intact, no
> corruption there. Your internal state might be corrupted - but how
On Sat, 13 Jul 2013 00:09:36 -0600
"Keith Medcalf" wrote:
> UPDATE WHERE CURRENT OF CURSOR has been part of SQL since about, oh,
> 1969.
(I assume that's dramatic license.)
> Now then SQLite does not support the FOR UPDATE OF clause when
> defining a cursor (ie, doing a prepare) which is int
On Mon, 29 Jul 2013 13:23:07 +0100
Simon Slavin wrote:
> INSERT OR IGNORE a new row with the correct 'word' and a confidence
> of 0
> UPDATE the row with that word to increment the confidence.
...
> If that solution doesn't work for you you might like to try first
> doing
>
> UPDATE myTable SET
On Wed, 7 Aug 2013 23:13:41 +0200
Petite Abeille wrote:
> On Aug 7, 2013, at 9:25 PM, Christopher W. Steenwyk
> wrote:
>
> > Ah, sorry about the attachments, you can find the files here:
> > https://www.dropbox.com/l/fpFfcjwwcyhXZgduswCggb
>
> Ah, also, your schema has a very, hmmm, Entity?att
On Wed, 14 Aug 2013 14:57:19 -0500
"Marc L. Allen" wrote:
> I'd actually like a compromise. Allow GROUP BY to accept a derived
> name if no base name exists. I realize that's against spec, but
> there's no ambiguity (as it otherwise errors out),
It would also mean the query's meaning could c
On Wed, 21 Aug 2013 20:26:30 +0100
Simon Slavin wrote:
> My problem is not with COLLATE in general. It's with expressions.
> Table definitions are fine. Index definitions are fine. It's purely
> that my understanding of the documention says that something like this
>
> "ABC" COLLATE COL1 = "3
On Thu, 22 Aug 2013 13:36:00 +0100
Simon Slavin wrote:
> > 1. where COLLATE( x AS NOCASE )
> > between COLLATE( 'a' AS NOCASE )
> > and COLLATE( 'b' AS NOCASE )
>
> Again, you are trying to apply a collation to a value. And because
> BETWEEN takes three operands you are
On Fri, 23 Aug 2013 17:08:59 +
Roman Fleysher wrote:
> This leads to enormous growth in number of types. Another solution is
> to realize that the comparator (the thing that makes comparisons) is
> actually an object of its own
An operation is not an object. SQL has no objects. The "enormou
On Mon, 26 Aug 2013 19:03:39 +
Roman Fleysher wrote:
> However, sometimes, in comparison we want to ignore some of the
> attributes, or compare derived ones. Many busses can carry 25 people,
> and may be considered equal if we simply need to transport people.
> Busses certainly differ by othe
On Mon, 26 Aug 2013 20:01:08 +0200
Clemens Ladisch wrote:
> sqlite3 database.db "UPDATE table1 SET column3 = CAST(x'$(hexdump -v
> -e '1/1 "%02x"' file.xml)' AS TEXT) WHERE column1 = 'some name';"
$ hexdump -C input
20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f | !"#$%&'()*+,-./|
0
On Tue, 27 Aug 2013 21:00:50 -0500
Nico Williams wrote:
> Of course, lacking a syntax for associating collations with string
> literals there will be times when some, or even all of the operands to
> an operation that needs collation information, is missing. In such
> cases the collation informa
On Sat, 31 Aug 2013 17:17:23 +0200
Etienne wrote:
> > On the other hand removing patterns definitely cannot hurt.
>
> Precisely.
>
> The very first bytes of SQLite files are, AFAIK, well known.
That's what salt is for, no?
--jkl
___
sqlite-users
On Fri, 30 Aug 2013 16:22:04 +
Doug Nebeker wrote:
> CREATE TABLE DevProps
> (
> CompID INTEGER NOT NULL,
> PropID INTEGER NOT NULL
> );
>
> CREATE UNIQUE INDEX Ind_DevProps_CompIDPropID on DevProps (CompID,
> PropID);
...
> SELECT CompID FROM DevProps WHERE PropID=33
>
> it looks like it w
On Wed, 28 Aug 2013 14:58:35 -0700 (PDT)
jdp12383 wrote:
> Each record is a recording up to 3 min. I am trying to retrieve one
> record per continuous recording.
...
> CREATE TABLE recordings (
> [key] INTEGERPRIMARY KEY ASC AUTOINCREMENT,
> filename VARCHAR(50),
On Sat, 31 Aug 2013 22:04:54 +0200
Petite Abeille wrote:
> > I changed the data (see below) because *meaning* of recordings.ends
> > should be an "exclusive end", what's knows as a half-open interval.
> > That makes the question of "does b follow a" one of equality. It is
> > likely not the case
On Tue, 3 Sep 2013 18:37:42 -0500
Nico Williams wrote:
> > There's no need to qualify string literals, as it turns out. SQLite
> > makes a reasonable choice in that context. When comparing a string
> > literal to a column, the literal (in effect) takes on the collation
> > of the column.
>
> Bu
On Tue, 3 Sep 2013 23:50:09 +0200
Eduardo Morras wrote:
> Don't know if column collation overrides index collation or viceversa.
It's probably simpler to think of them as two things, table and index.
Neither "overrides" the other.
Ideally, they use the same collation. In the event not, I wou
On Tue, 3 Sep 2013 18:43:52 -0600
Jared Albers wrote:
> When using relatively long table names like `TABLE_{table #}_{some
> unique identifying name that adds 120 or so characters}`, creation of
> a database with 10,000 tables takes approximately 60 seconds.
I find this a very strange course of
On Thu, 5 Sep 2013 19:53:15 +0100
Simon Slavin wrote:
> On 5 Sep 2013, at 7:20pm, Peter Haworth wrote:
>
> > That works fine but wondering if there might be a single UPDATE
> > statement that could do this for me. I can use the WHERE clause to
> > select sequence 3,4, and 5 but the UPDATE has
On Fri, 6 Sep 2013 11:07:27 -0400
Richard Hipp wrote:
> The effect of early row updates might be visible in later row updates
> if you contrive a sufficiently complex example. But you really have
> to go out of your way to do that.
sqlite> create table i ( i int primary key );
sqlite> insert
On Fri, 6 Sep 2013 07:56:53 -0500
"Marc L. Allen" wrote:
> I don't think it's a bug.
It is a bug as long as the behavior is in exception to the
documentation.
> I don't believe there's any defined rule for how SQL should behave,
> is there?
Of course there is. Hundreds of pages describe
On Fri, 6 Sep 2013 17:29:25 +
Harmen de Jong - CoachR Group B.V. wrote:
> > If I recall correctly, query planner's behavior is worst-case
> > quadratic in the number of tables participating in the query. This
> > includes tables mentioned directly, and also those pulled in
> > indirectly via
On Fri, 6 Sep 2013 17:45:59 -0400 (EDT)
j.merr...@enlyton.com wrote:
> I propose that you remove the unique index because SQLite does not
> handle the update case the way you want.
The correct general approach, in light of observed behavior,
1. begin IMMEDIATE transaction
2. select rows into
On Sun, 8 Sep 2013 22:56:20 +
"Joseph L. Casale" wrote:
> What is the most efficient way to insert several records into a table
> which has a fk ref to the auto incrementing pk of another insert I
> need to do in the same statement.
If I understand the question, and there is no key other tha
On Tue, 10 Sep 2013 12:58:21 +
Harmen de Jong - CoachR Group B.V. wrote:
> I think the way I wrote our timings were not that clear, since they
> are definately exponentially. The numbers from my previous post refer
> to the multiplier between the test cases. Just to make it clear, here
> foll
On Mon, 9 Sep 2013 02:17:00 +
"Joseph L. Casale" wrote:
> > If I understand the question, and there is no key other than the
> > auto-incrementing integer, there might not be a good way. It
> > sounds like the database's design may have painted you into a
> > corner.
>
> Well, after inser
On Thu, 12 Sep 2013 18:15:29 +
"Joseph L. Casale" wrote:
> > If you make val unique -- and I see no reason not to -- then you
> > can select the id for every val you insert with "where val =
>
> I omitted the fact that val in table_a is unique.
Ah, that will be very helpful.
> Sending on
On Thu, 12 Sep 2013 14:01:04 +0100
Simon Davies wrote:
> Why not
> SELECT * FROM "entry" WHERE
>bankdate >= date('now','start of month')
> AND bankdate < date('now','start of month','+1 month')
The half-open interval strikes again! :-)
--jkl
__
On Sat, 14 Sep 2013 17:19:22 +0400
Yuriy Kaminskiy wrote:
> > Notwithstanding the timezone you want to use,
> >
> > explain select *
> > from entry
> > where bankdate >= date('now', 'start of month')
> >and bankdate < date('now', 'start of month', '-1 day');
>
On Mon, 16 Sep 2013 10:38:03 -0400
Richard Hipp wrote:
> one can easily imagine that one or
> more of those two million applications does something like this:
>
> SELECT current_timestamp, * FROM tab;
>
> And then runs sqlite3_step() every five or ten seconds in a background
> process to f
On Sat, 21 Sep 2013 15:06:14 +0100
Simon Slavin wrote:
> > If I "SELECT * FROM Groceries" to list all records, how do I
> > arrange a query to list each record in the groceries table with all
> > matching history items under each record.
>
> You do it with two queries, not one. In all seriousne
On Sat, 21 Sep 2013 00:28:15 +0100
Simon Slavin wrote:
> Your extremely long SELECT with its sixteen COALESCEs and eight LEFT
> OUTER JOINs suggests that you have a schema which doesn't really suit
> the 'shape' of your data. Another hint pointing in the same
> direction is numbered database nam
On Tue, 24 Sep 2013 20:21:09 +0200
Petite Abeille wrote:
> On Sep 24, 2013, at 8:05 PM, Simon Slavin
> wrote:
>
> > Which is why you do an INSERT first, and allow it to fail, then do
> > the UPDATE.
>
> Sure. A lot of error proce procedural code to do what one SQL
> statement could do much mor
On Sun, 6 Oct 2013 22:58:28 +1000
Paul L Daniels wrote:
> "Undark" is only at v0.2 at this time, it's still quite coarse
> around some corners and it does not differentiate between
> deleted and undeleted rows. It also has a limitation of only
> decoding what it finds wit
On Mon, 07 Oct 2013 12:48:10 +0100
dean gwilliam wrote:
> Here's my miserable attempt
> gDb eval "UPDATE itms SET std_nm=(SELECT std_nm FROM aliases as x
> WHERE raw_nm = x.raw_nm);"
Oh, so close!
An update statement without a WHERE clause updates the whole table.
In your case, any rows in it
On Wed, 09 Oct 2013 10:20:13 -0400
Ryan Johnson wrote:
> > This is more portable:
> >
> > #ifdef SQLITE_64BIT_STATS
> > sqlite3_snprintf(24, zRet, "%lld", p->nRow);
> > #else
> > sqlite3_snprintf(24, zRet, "%d", p->nRow);
> > #endif
> Actually, some machines define 64-bit ints
On Wed, 9 Oct 2013 17:00:36 -0400
"jose isaias cabrera" wrote:
> CREATE TABLE SimplePrices (
> cust TEXT,
> class TEXT,
> slang TEXT,
> tlang TEXT,
> TransferCost,
> Price,
> PRIMARY KEY (cust, class, slang,
On Thu, 10 Oct 2013 12:29:21 -0400
"jose isaias cabrera" wrote:
> > INSERT INTO SimplePrices
> > SELECT cust || '1', class, slang, tlang, TransferCost, Price
> > FROM SimplePrices WHERE cust = 'XEROX';
> >
> > Kudos for the primary key declaration, btw. :-)
>
> Thanks for the kudos and the supp
On Thu, 10 Oct 2013 16:27:21 +0200
Stephan Beal wrote:
> > (echo .separator "||"; echo .import path tbl) | sqlite3 dbfile
> >
>
> Alternately, most Unix shells allow:
>
> echo -e ".separator '[||'\n.import ..."
>
> the -e enables the conventional set of backslash escapes.
We're OT here, but
On Fri, 18 Oct 2013 13:57:18 -0400
"Normand Mongeau" wrote:
> Also, the consuming should be a 2-step process because the processing
> is involved and may fail for reasons too long to explain here. So in
> essence, select a record, modify it to indicate it's being processed,
> and once the process
On Sat, 19 Oct 2013 21:21:44 +0530
Raheel Gupta wrote:
> CREATE INDEX map_index ON map (n, s, d, c, b);
>
> The above table is having nearly 600 Million Records and is of size
> 26 GB. The column 'n' is representing Numbers of Blocks on the file
> system. 's' stands for Snapshot ID.
> 'd' is dev
On Sat, 19 Oct 2013 20:07:22 +0200
Clemens Ladisch wrote:
> > It seems to be using the the covering index which I guess is the
> > fastest way as Sqlite doesnt need to check the actual table. So why
> > would it slow down and use so much CPU in my last query ?
>
> In theory, a multi-column index
On Sun, 20 Oct 2013 17:08:09 +0400
Yuriy Kaminskiy wrote:
> > The new INDEX that I created on your suggestion with d,n,s solves
> > the problem.
> > Now the question is over Primary key whether that will slow it down
> > or not.
>
> Only question is whether you have *other* queries that prefers
On Sun, 20 Oct 2013 16:53:30 +0530
Raheel Gupta wrote:
> I need the inserts to be faster.
Faster than what? Why can the existing hardware not be replaced?
I would be interested to hear what you find out testing your
performance with the primary key in place. I doubt it will be very
differen
On Fri, 25 Oct 2013 12:11:42 -0700
"Joe.Fisher" wrote:
> Is it possible to import data by column number without using any
> delimiters?
>
> We have massive text based data files where each record of the data
> is segmented and consistent (Col 1-3, 4-9, 10-12, etc.).
awk is your friend.
Here'
On Sat, 2 Nov 2013 18:06:30 +0100
Gert Van Assche wrote:
> CREATE TABLE T (N, V, G);
> INSERT INTO T VALUES('a', 1, 'x');
> INSERT INTO T VALUES('b', 3, 'x');
> INSERT INTO T VALUES('c', null, 'x');
> INSERT INTO T VALUES('d', 80, 'y');
> INSERT INTO T VALUES('e', null, 'y');
> INSERT INTO T VALU
On Mon, 4 Nov 2013 13:01:37 +0100
Gert Van Assche wrote:
> Thanks James -- the select query is something I could do, but the
> update one I could not get that one right.
> I was considering to create a new table based on the select query,
> but since the real data set is millions of records, an
On Thu, 7 Nov 2013 14:50:44 +0400
dd wrote:
> I am working on sqlite database schema for Music/Track files. I am
> posting few tables schema here.
>
> CREATE TABLE if not exists AllFilesTbl (Id INTEGER PRIMARY KEY
> AUTOINCREMENT, file_path TEXT NOT NULL, file_type INTEGER NOT NULL,
> UNIQUE(f
On Tue, 14 Oct 2014 18:21:27 -0400
Ross Altman wrote:
> Yeah, that's actually a really good point. Oh well, I guess I'll just
> have to hope that people decide to use the database responsibly...
> haha
You can advertise your database with the tagline, "Please compute
responsibly".
The first r
On Thu, 16 Oct 2014 09:05:51 +1100
Michael Falconer wrote:
> we just wonder if there is a better way to perform this search in
> SQL. Is there a general technique which is superior either in speed,
> efficiency or load bearing contexts?
The simple answer is No, because SQL is a specification, no
On Fri, 24 Oct 2014 21:44:50 +0400
dd wrote:
> >>Convert everything to upper (or lower) case brute force.
>Sorry. I am not clear. Can you please elaborate this.
The standard function tolower(3) is locale-dependent. If your locale is
set to match the data's single-byte encoding,
On Sun, 26 Oct 2014 15:27:24 +0300
Baruch Burstein wrote:
> I need to get the path with the
> first 2 parts stripped off. Currently I am doing:
>
> substr(path, 4+instr(substr(path,4),'/'))
>
> But that seems long and probably inefficient.
> What is the best/simplest way to find the sec
On Mon, 27 Oct 2014 12:33:59 +0100
Steinar Midtskogen wrote:
> Is there a way to prevent the -wal and -shm files from being deleted
> after use, so that I can have them always have the right group? Or is
> there a way to tell Linux to observe the setgid flag on a directory
> (ext4)?
See -o grpi
On Mon, 27 Oct 2014 16:49:42 -0500
Nico Williams wrote:
> If it's not too much to ask for then SQLite3 ought to: a) check for
> duplicates by canonicalized path (but keep in mind that this can be
> difficult to do portably, or without obnoxious length limitations on
> Windows),
The name is not
On Mon, 27 Oct 2014 17:41:53 +0100
Steinar Midtskogen wrote:
> "James K. Lowden" writes:
>
> > See -o grpid in mount(8). I think that's what you want.
>
> Thanks. It works!
Hmm, I'm glad, but as David Woodhouse pointed out, it shouldn't have
bee
On Wed, 29 Oct 2014 20:38:07 +0200
Baruch Burstein wrote:
> If I have a table, "t", with 2 columns, "a" and "b". Assuming that
> "a" is a unique number, will the following query always return the
> whole row (that is, with the correct "b" column) where "a" is the
> highest number below 50?
>
> S
On Thu, 30 Oct 2014 17:37:54 +0100 (CET)
Carsten Kunze wrote:
> the man page sqlite3.1 contains the .cc request which is not
> compatible with the man macro package (and hence must not be used in
> a man page).
The below patch rectifies that problem and clears up some others
besides:
1. re
On Sat, 01 Nov 2014 11:06:51 +0200
Paul wrote:
> Would be nice to have ability to store both key and payload in the
> index. (Let's call it index-only table)
> This could be a feature that sets some limitations on a table, like
> being unable to have more than one index or inefficient table scans
On Mon, 03 Nov 2014 11:50:17 +0200
Paul wrote:
> > > Would be nice to have ability to store both key and payload in the
> > > index. (Let's call it index-only table)
> > > This could be a feature that sets some limitations on a table,
> > > like being unable to have more than one index or ineffic
On Tue, 4 Nov 2014 12:06:35 +
Simon Davies wrote:
> > And watch as it crashes when creating the index.
>
> From https://www.sqlite.org/compile.html:
>
> Important Note: The SQLITE_OMIT_* options do not work with the
> amalgamation or with pre-packaged C code files. SQLITE_OMIT_*
> compile-t
On Tue, 04 Nov 2014 22:20:23 +0200
RSmith wrote:
> The best way to think of the 64 bit upgrade in normal programming is:
> "Able to do larger accuracy calculations at more or less the same
> speed".
Eh, more accurate how? Every 32-architecture I compiled for supported
64-bit long integers. Flo
On Tue, 4 Nov 2014 21:47:20 +
"Drago, William @ CSG - NARDAEAST" wrote:
> I've been pulling my hair out trying to figure how to use EXISTS.
I have several examples at
http://www.schemamania.org/sql/#missing.table.
> Is there a better/recommended way in SQLite to check if a record
> exists
On Wed, 05 Nov 2014 08:24:47 -0700
"Keith Medcalf" wrote:
> The two queries are different. They may end up with the same result,
> but you are asking different questions. In the first you are
> returning only matching rows. In the later you are requesting a
> projection (outer join) then apply
On Thu, 6 Nov 2014 17:02:26 -0500
Richard Hipp wrote:
> > sqlite> INSERT INTO test VALUES ('b'), ('A'), ('B'), ('a');
> > sqlite> SELECT * FROM test;
> > b
> > A
> > B
> > a
...
> > sqlite> SELECT * FROM test WHERE LTRIM(col)<'b';
> > A
> > B
> > A
...
> Works as designed. See
> https://www.sqli
On Sat, 08 Nov 2014 22:55:46 +0900
Tristan Van Berkom wrote:
> So I would have to say, the "right way to do it" is the most efficient
> way, the one which provides SQLite with the best indications of how
> to plot an efficient query plan.
Keith is suggesting that the right way to do it is neithe
On Sun, 09 Nov 2014 00:45:16 +0900
Tristan Van Berkom wrote:
> While I do understand SQL as a functional language, most functional
> programming I've done still has rather explicit syntax/rules, so I get
> particularly uncomfortable with writing vague statements, such as
> JOIN tableA, tableB WHE
ECT * FROM test WHERE LTRIM(col)<'b';
> > A
> > B
> > A
--jkl
>
> -Ursprüngliche Nachricht-
> Von: James K. Lowden [mailto:jklow...@schemamania.org]
> Gesendet: Samstag, 08. November 2014 01:52
> An: sqlite-users@sqlite.org
> Betreff: Re:
On Tue, 11 Nov 2014 17:15:53 -0600
Ben Newberg wrote:
> CREATE TRIGGER t_populate_zweeks
> AFTER UPDATE ON zSPs WHEN new.Procedure = 6 AND new.Flag = 1
> BEGIN
> DELETE FROM zWeeks;
> WITH RECURSIVE Weeks(wk) as (select 1 union all select wk + 1 from
> Weeks limit 10)
> INSERT INTO zWeeks (Week)
On Thu, 13 Nov 2014 14:38:10 +
Simon Slavin wrote:
> In summary, if you need ultimate precision, use integers. If not,
> use 64-bit IEEE-571 like everyone else does without being sued. If
> you somehow really need 23,10 maths, then you're going to have to
> write your own mathematical libra
On Mon, 17 Nov 2014 12:00:06 +
Hick Gunter wrote:
> SELECT table_name FROM sqlite_master;
>
> And then, in your programming language of choice, execute
Or, with some determination, you can do it in two steps in pure SQL:
Use SQL to produce SQL, and execute the result,
SELECT's
On Tue, 18 Nov 2014 12:06:02 +
Simon Slavin wrote:
> > my requirement, which is using a
> > table name as a variable
>
> This is deliberately made very difficult in SQL. I think it's for
> security reasons.
That may be part of it, but It's really all about values.
SQL has value semantic
On Fri, 21 Nov 2014 14:01:39 -0500 (EST)
Joseph Fernandes wrote:
> 4) Therefore, we are looking at a datastore that can give us a very
> quick write(almost zero latency, as the recording is done inline
> w.r.t file IO) and that as good data querying facilities(Slight
> latency in the read is fine
On Sat, 22 Nov 2014 23:25:16 -0500 (EST)
Joseph Fernandes wrote:
> 2) Using the changelog to feed the db has another issue i.e freshness
> of data in the DB w.r.t the IO. Few of our data maintainer scanners
> would require the freshness of the feed to be close to real. [...]
> Your thoughts on th
Darko,
I have rather a long answer for you. I'm not confused about the
difference between logical and physical types, but I am confused about
what you meant and what you're hoping to accomplish.
On Wed, 26 Nov 2014 03:22:03 -0800
Darko Volaric wrote:
> A 64 bit floating point number and an
On Tue, 02 Dec 2014 15:58:47 +0100
Abramo Bagnara wrote:
> The point is not about overzealousness, but about the declaration of
> memcpy/memset on your machine.
>
> If it contains the nonnull attribute then (correctly) UBSan detect
> that such constraint is not respected.
Hmm, I guess you mean
On Wed, 03 Dec 2014 08:56:44 +0100
Clemens Ladisch wrote:
> James K. Lowden wrote:
> > /* Copy N bytes of SRC to DEST. */
> > extern void *memcpy (void *__restrict __dest,
> > __const void *__restrict __src, size_t __n)
> > __THROW __nonnull
On Mon, 08 Dec 2014 22:01:15 +0700
Dan Kennedy wrote:
> On 12/08/2014 09:55 PM, Nico Williams wrote:
> > Ideally there would be something like DEFERRED foreign key checking
> > for uniqueness constraints...
>
> You could hack SQLite to do enforce unique constraints the same way
> as FKs. When ad
On Mon, 08 Dec 2014 15:48:41 +0200
RSmith wrote:
> > UPDATE pages SET position = position + 1 WHERE book_id = 0 AND
> > position >= 1;
>
> NOT a bug... the moment you SET position to position +1 for the
> first iteration of the query, it tries to make that entry look like
> (0,2) and there is o
On Mon, 08 Dec 2014 20:57:00 -0500
Igor Tandetnik wrote:
> Yes, there are workarounds (a view; or REPLACE INTO may sometimes be
> pressed into service). But I, for one, kinda miss UPDATE ... FROM.
Be careful what you wish for. :-)
The only implementation of UPDATE...FROM that I know is on S
On Tue, 09 Dec 2014 12:06:20 +0100
Jan Stan?k wrote:
> INSERT INTO CoreCache (ModelID, ItemID)
> SELECT
...
> ORDER BY Year
Why ORDER BY on INSERT? Does it work better? I would expect the
unnecessary sort to be pure overhead.
--jkl
___
sqlite-
On Wed, 10 Dec 2014 08:49:21 +0100
Eduardo Morras wrote:
> > Why ORDER BY on INSERT? Does it work better? I would expect the
> > unnecessary sort to be pure overhead.
>
> If you insert in correct index order, the index update phase is
> faster because it don't need rebalance the b-tree so of
On Tue, 09 Dec 2014 10:46:23 -0500
Igor Tandetnik wrote:
> On 12/9/2014 10:38 AM, James K. Lowden wrote:
> > If the subquery to the right of the SET clause produces
> > more than one row, the statement fails.
>
> Are you sure? Normally, a scalar subquery doesn't
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 selecting a large table a
On Thu, 25 Dec 2014 05:32:45 -0700 (MST)
Rick Kelly wrote:
> All SELECT type requests are wrapped with BEGIN TRANSACTION/COMMIT
That shouldn't be necessary and afaik isn't necessary. SELECT does not
modify the database. To "commit a select" is to apply the nonchanges.
A common misconceptio
On Sun, 28 Dec 2014 17:46:08 +0100
Tomas Telensky wrote:
> select kvadrat, datum, count(distinct kontrola) as pocet
> from b
> group by kvadrat, datum
> having pocet > 1
>
> The problem was that pocet was actually a column in table b and I
> didn't notice, and the having clause was using the tab
On Fri, 2 Jan 2015 16:12:23 -0800
J Decker wrote:
> I understand it's kept as a string...
It might be more helpful to think of it not in terms of how it's "kept"
but as what its type is. How it's kept is up to the DBMS to decide.
But the column is of a type: one of text, integer, and double.
On Mon, 5 Jan 2015 06:39:42 +
Hick Gunter wrote:
> This is completely legal and well defined.
>
> HAVING is applied to the RESULT set of a SELECT.
I beg to differ. It's both invalid SQL and (therefore) undefined.
Furthermore, it's illogical. Consider:
create table T (a int, b int
On Fri, 02 Jan 2015 21:41:02 -0700
"Keith Medcalf" wrote:
> On Friday, 2 January, 2015 16:26, James K. Lowden
> said:
>
> >On Thu, 25 Dec 2014 05:32:45 -0700 (MST) Rick Kelly
> > wrote:
>
> >> All SELECT type requests are wrapped with BEGIN TRANSACTI
On Wed, 07 Jan 2015 21:47:24 -0700
"Keith Medcalf" wrote:
> >As I said, your description (which I trust is accurate) is very
> >helpful to someone who wants to understand how SQLite will act on
> >the SQL provided to it. But it also protrays problematic choices
> >that stray from SQL's defined b
On Thu, 8 Jan 2015 08:42:25 +
Hick Gunter wrote:
> It is legal and well defined in SQLite. See the explain output below.
> This is because of the well-documented feature of SQLite that columns
> that are neither GROUPED BY nor aggregated will have a defined value.
OK, understood, "in SQLite"
On Sat, 10 Jan 2015 00:58:25 -0700
"Keith Medcalf" wrote:
> > there's no way to hook two SELECTs together to make them see one
> >database state. That's what JOIN is for. :-)
>
> Yes, it is a part of the SQL Standard isolation levels in excess of
> the default default of READ COMMITTED. Differ
Hello all,
I had the bright idea yesterday of trying to use an extension module in
Windows. I found myself a bit confused, and the messages and
documentation were not as helpful as they might have been. I suspect I
had a 32/64 bit mismatch in one case, and that sqlite3 wasn't compiled
with exte
On Fri, 16 Jan 2015 10:38:54 -0800
Dave Dyer wrote:
> [$] sqlite3 po.sqlite .dump | sqlite3 po2.sqlite
> Error: incomplete SQL: INSERT INTO "imageblob" VALUES(1,'G:\share
Perhaps try -echo, to display the incomplete SQL?
I'm skeptical of the notion that cmd.exe is diddling with your data en
r
501 - 600 of 694 matches
Mail list logo
