> No, I am not asking SQLite to "emulate an error" in Adobe's code. Rather I > am suggesting this: if SQLite is going to distinguish in any way between INT > and INTEGER on primary key definitions, the CREATE TABLE X as SELECT... > syntax ought not to produce a table with an INT primary key if the prototype > had INTEGER.
Tim, why do you keep insisting on your claim that came out of thin air? I first thought that it has some ground under it but as Jay said and as below log shows you are totally wrong. SQLite version 3.6.23.1 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> create table t (id integer primary key, t text); sqlite> .s CREATE TABLE t (id integer primary key, t text); sqlite> insert into t values (1, '1'); sqlite> insert into t values (999, '999'); sqlite> create table t_copy as select * from t; sqlite> .s CREATE TABLE t (id integer primary key, t text); CREATE TABLE t_copy(id INT,t TEXT); sqlite> You see? There's no INT PRIMARY KEY and there will never be. So Adobe will never be confused with your copied table because it as well as SQLite will understand that new table doesn't have primary key at all. And in this case it doesn't matter whether you have INT or INTEGER. So what are you fighting for after all? Pavel On Thu, Jul 1, 2010 at 7:41 AM, Tim Romano <tim.romano...@gmail.com> wrote: > If cross-implementation portability is a stated design goal, Adobe's > departure from the "authoritative" behavior is indeed a bug. If > cross-implementation portability is not "officially" supported but is simply > something that users might expect and attempt, then Adobe's departure from > the authoritative behavior is just a pothole on the lonely highway. > > I don't know the particulars of how it happened. I think Adobe may not have > envisioned SQLite database files created outside of AIR being used in AIR > apps. They were probably thinking in terms of "local storage" databases > instantiated and defined through the AIR API. > > No, I am not asking SQLite to "emulate an error" in Adobe's code. Rather I > am suggesting this: if SQLite is going to distinguish in any way between INT > and INTEGER on primary key definitions, the CREATE TABLE X as SELECT... > syntax ought not to produce a table with an INT primary key if the prototype > had INTEGER. > > > Regards > Tim Romano > Swarthmore PA > > > > On Wed, Jun 30, 2010 at 9:24 AM, David Bicking <dbic...@yahoo.com> wrote: > >> >> >> All things considered, I would say this is clearly and 100% a bug in >> Adobe's code. The given SQL nowhere mentioned rowid, yet they are >> joining on rowid... that has got to be an error. >> >> And how is Adobe Air doing this? Did they write there own sql parser? >> There own VDBE? (Hopefully I got those initials correct.) Are they >> calling Sqlite or did they write their own library claiming it is >> compatible with the Sqlite file format? >> >> While I don't necessarily disagree with what you are saying, in this >> example you appear to be asking the Sqlite developers to emulate an >> error in someone else's code. >> >> David >> >> PS. Probably should remove my opinions from this, because the only >> reason I am sending this is because I am curious what the hell Adobe is >> doing that is causing this confusion. >> >> >> >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
