[sqlite] POSIX and MMU (was Re: out of the void: xDlSym)
Scott Robison wrote: > On Sat, Jan 16, 2016 at 1:58 PM, James K. Lowden > wrote: > >> On Fri, 15 Jan 2016 21:41:41 -0500 >> Richard Damon wrote: >> >>> there are machines where it doesn't work (you just need a larger >>> program space than data space). >> >> Huh. An example of which is the "medium model" of the Intel 8086: >> 20-bit code pointers and 16-bit data pointers. A machine for which C >> compilers existed, and on which no Posix system will ever run (because >> it lacks an MMU). Thanks for that. >> > > Sorry for the OT diversion, but I'm just curious as I don't have historical > POSIX standards for reference. Does POSIX really *require* an MMU? > Certainly Unix like systems were written for 8086 class computers, but > given that POSIX was first standardized in 1988 I'm just curious as to > whether or not an MMU is a requirement or just really nice to have. ST-Minix ran on MC68000 - no MMU. POSIX API only defines a programming model, it doesn't mandate how it gets implemented under the covers. An MMU *can* make some things easier, but we had fork/exec etc. even without it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
[sqlite] POSIX and MMU (was Re: out of the void: xDlSym)
On Sun, Jan 17, 2016 at 1:33 PM, Howard Chu wrote: > Scott Robison wrote: > >> Sorry for the OT diversion, but I'm just curious as I don't have >> historical >> POSIX standards for reference. Does POSIX really *require* an MMU? >> Certainly Unix like systems were written for 8086 class computers, but >> given that POSIX was first standardized in 1988 I'm just curious as to >> whether or not an MMU is a requirement or just really nice to have. >> > > ST-Minix ran on MC68000 - no MMU. POSIX API only defines a programming > model, it doesn't mandate how it gets implemented under the covers. > > An MMU *can* make some things easier, but we had fork/exec etc. even > without it. That's what I thought, but haven't spent enough time with it (from a standards document perspective) to have certain knowledge. Thanks. -- Scott Robison
[sqlite] POSIX and MMU (was Re: out of the void: xDlSym)
On Sun, Jan 17, 2016 at 10:09 AM, James K. Lowden wrote: > On Sat, 16 Jan 2016 14:21:26 -0700 > Scott Robison wrote: > > > > Huh. An example of which is the "medium model" of the Intel 8086: > > > 20-bit code pointers and 16-bit data pointers. A machine for which > > > C compilers existed, and on which no Posix system will ever run > > > (because it lacks an MMU). Thanks for that. > > > > > > > Sorry for the OT diversion, but I'm just curious as I don't have > > historical POSIX standards for reference. Does POSIX really *require* > > an MMU? Certainly Unix like systems were written for 8086 class > > computers, but given that POSIX was first standardized in 1988 I'm > > just curious as to whether or not an MMU is a requirement or just > > really nice to have. > > AFAIK Posix makes no statement regarding hardware. And Posix systems > do run on "machines" today without an MMU, if you count bochs as a > "machine" and disregard the MMU supplied by the underlying hardware. > Posix requires process separation, which is most efficiently > implemented in hardware, and was definitely needed back in the days of > 4.77 MHz processors. > No, I was thinking actual real hardware. If including virtual machines I'd have to consider a virtual MMU to be an MMU. > Xenix ran on the 8086, to be sure. As best I remember, though, the > Xenix that run on a stock IBM PC was single-threaded: no fork(2). > Sorry, no links; the www can be skimpy on pre-1990 arcania. Apparently > there were real multitasking versions of Unix running on the 8086, > where the motherboard included some form of MMU. I'm sure they > performed like dancing bears. > Indeed it can be skimpy, hence my asking. I was hoping you might have information I was unable to find. Obviously Unix and Xenix and anything that was released prior to 1988 was not written with Posix conformance in mind. I was mainly curious if it legally required an MMU (per the standard). Thanks! -- Scott Robison
[sqlite] POSIX and MMU (was Re: out of the void: xDlSym)
On Sat, 16 Jan 2016 14:21:26 -0700 Scott Robison wrote: > > Huh. An example of which is the "medium model" of the Intel 8086: > > 20-bit code pointers and 16-bit data pointers. A machine for which > > C compilers existed, and on which no Posix system will ever run > > (because it lacks an MMU). Thanks for that. > > > > Sorry for the OT diversion, but I'm just curious as I don't have > historical POSIX standards for reference. Does POSIX really *require* > an MMU? Certainly Unix like systems were written for 8086 class > computers, but given that POSIX was first standardized in 1988 I'm > just curious as to whether or not an MMU is a requirement or just > really nice to have. AFAIK Posix makes no statement regarding hardware. And Posix systems do run on "machines" today without an MMU, if you count bochs as a "machine" and disregard the MMU supplied by the underlying hardware. Posix requires process separation, which is most efficiently implemented in hardware, and was definitely needed back in the days of 4.77 MHz processors. Xenix ran on the 8086, to be sure. As best I remember, though, the Xenix that run on a stock IBM PC was single-threaded: no fork(2). Sorry, no links; the www can be skimpy on pre-1990 arcania. Apparently there were real multitasking versions of Unix running on the 8086, where the motherboard included some form of MMU. I'm sure they performed like dancing bears. --jkl
[sqlite] Updating the contents of a field in table A with the value of the same field in table B
On Sat, 16 Jan 2016 14:26:20 -0700 "Keith Medcalf" wrote: > > the result is nondeterministic if more than one row in S matches. > > The update applies all rows in S matching T. Of course, only the > > last one is preserved. Of course, because order is nonsemantic, > > there's no way to know *which* S row will "win". > > And the problem is exactly what? The statement will do exactly and > precisely what it has been instructed to do. That it was given bad > instruction by someone incompetent to be giving instruction is > irrelevant. It's not a "bad instruction" to update one table from another when the join criteria aren't guaranteed, by DRI, to be 1:1 correspondence. Either the instruction can be carried out consistent with the database's constraints, or it cannot. A logically incoherent instruction -- such as "update row 1 in T from rows 2-5 in S -- should be rejected as erroneous. The system should not apply row 5 and ignore 2-4 arbitrarily. It is a bad implementation that allows an update statement to have nondeterministic results. I would think we agree on that. > The real problem with implementing this sort of update is that it in > order to prevent implementation errors (caused by the fact that the > set algebra is performed one row at a time, and not as a set) you > have to generate and intermediate update set and then apply that set > after the fact -- if a column being updated is used in a join > constraint (but not if it is used in a selection constraint). I'm not sure I understand. I guess by "set algebra is performed one row at a time" you're describing implementation, but of course all implementation is one row at a time (if that). Do you simply mean the semantics of the update preclude efficient implementation? Sure, that's something to be aware of. Is it a "problem", per se? I'm on record asking for more correct, even if less efficient, implementation in SQLite. Specifically, it shouldn't be necessary to drop unique constraints to increment consecutive values. --jkl
[sqlite] SQLite3 with support for _Decimal64 on github
Hello ! I finally got time to publish my changes to sqlite3 to allow the use of _Decimal64/double/int64 as floating point unit by defining SQLITE_USE_DECIMAL, almost all tests pass with exception of direct binary manipulation of doubles (_Decimal64 have different binary representation) and "with1-8.1-mandelbrot" which is 3 characters short. It's availlable here https://github.com/mingodad/sqlite/tree/decimal64 . Any feedback is welcome ! Cheers !
[sqlite] Parsing the contents of a field
On 2016/01/16 4:53 PM, Simon Slavin wrote: > On 16 Jan 2016, at 2:31pm, R Smith wrote: > >> There is of course no SQL function to do this, but thanks to CTE we can >> achieve it easily (though not extremely efficiently). > I thought that WITH could be used only for SELECT statements. > > Oh wait, you want to use the WITH statement as a sub-select on an INSERT > statement. Does that work ? The example I posted simply SELECTs the values, but it can as easily be piped to a table via an INSERT statement or such. The OP said indeed he wants to push the values to a table and from there read it. This can even be an in-memory table or simply another CTE table. As to your question - WITH can be used in any place where a table-select can, with some restrictions (though my example requires nothing fancy in this regard). I quote from the documentation at: https://www.sqlite.org/lang_with.html "All common table expressions (ordinary and recursive) are created by prepending a WITH clause in front of a SELECT, INSERT, DELETE, or UPDATE statement. A single WITH clause can specify one or more common table expressions" That is to say, it is perfectly legal to do something like this: WITH C(Idx) AS ( SELECT 1 UNION ALL SELECT Idx+1 FROM C OFFSET 5 LIMIT 3 ) DELETE FROM Contacts WHERE EXISTS (SELECT 1 FROM C WHERE C.Idx=Contacts.ID); Which will delete contacts from the "Contacts" table with ID's 6, 7 and 8. Or perhaps: WITH NewPeeps(title, name, surname, tel, email) AS ( SELECT 'James', 'Jones', '555-123-7689' UNION ALL SELECT 'Jason', 'Johnson', '555-124-7689' UNION ALL SELECT 'Jeffrey', 'Jenner', '555-125-7689' ) INSERT INTO Contacts (Name, Surname, Title, Tel, Mail) SELECT name, surname, 'Mr.', tel, name||'@jworld.org' FROM NewPeeps; Which will insert the contacts into the Contacts table. Etc. Even in explicit sub-selects it works perfectly well, for example this query: SELECT * FROM ( WITH C(Idx) AS (SELECT (10+1) UNION ALL SELECT Idx+2 FROM C WHERE Idx<(20-1)) SELECT * FROM C ) Which will produce all odd numbers between 10 and 20. And then this Query will list all contacts with ID's that are the odd numbers between 10 and 20: SELECT * FROM Contacts, ( WITH C(Idx) AS (SELECT (10+1) UNION ALL SELECT Idx+2 FROM C WHERE Idx<(20-1)) SELECT * FROM C ) AS S WHERE IndexC=S.Idx Or in a correlated sub-query: SELECT ( WITH C(Idx, SqrIdx) AS ( SELECT 1,1 UNION ALL SELECT Idx+1, (Idx*Idx) FROM C WHERE Idx<1000 ) SELECT SqrIdx FROM C WHERE C.Idx=Contacts.ID LIMIT 1 ) AS SQR, Contacts.* FROM Contacts which shows the square of contact ID's next to the rest of their data. These examples are of course extremely simple, but they show the principles.
[sqlite] Parsing the contents of a field
On 17 Jan 2016, at 12:27am, R Smith wrote: > I quote from the documentation at: https://www.sqlite.org/lang_with.html > > "All common table expressions (ordinary and recursive) are created by > prepending a WITH clause in front of a SELECT, INSERT, DELETE, or UPDATE > statement. A single WITH clause can specify one or more common table > expressions" Ah, I missed that. I thought it was just SELECT. Thanks. Simon.
