Pavel Ivanov wrote: >> 2. *re integer vs string:* Version 3 differs from version 2 here. >> Version 2 was declared to be typeless and "Select Where column = >> 1" behaved identically with "Select Where column = '1'". Version >> 3 behavior is different in that the two previous examples produce >> different results, a compatibility issue. >> > > Version 3 also differs from version 2 in that all functions are named > starting with 'sqlite3_' instead of 'sqlite_'. Doesn't this make > another compatibility issue to complain about? Why didn't you mention > it at all? > AFAIK, SQLite 3 never tried to say that it is fully > backward-compatible with SQLite 2. > > I only reported problems that I had actually encountered in migrating to version 3. I never had occasion to use the function names you mentioned. *re backward compatibility:* OTOH, it doesn't say that it is NOT backward compatible w/r/t the syntax and semantics of the language. As a user contemplating an upgrade, I would expect such differences to be prominently discussed. >> The v3 document (in discussing conversions) uses the expression >> "affinity is applied" without defining what that means. Does it >> mean "conversion to"? >> > > Read about affinities and how are they applied here: > http://www.sqlite.org/datatype3.html. > Yes, that is where I looked to find what "applied affinity" meant, but never found a crisp definition. If it means "converted to", it should say that. > > Pavel > > On Thu, Sep 3, 2009 at 6:31 AM, Rod Dav4is<dav...@yahoo.com> wrote: > >> 1. *re OID vs ROWID:* I don't understand your statement that the >> "name" of a result column is undefined. The documentation clearly >> states "A column name can be any of the names defined in the >> CREATE TABLE statement or one of the following special >> identifiers: "*ROWID*", "*OID*", or "*_ROWID_*"." If I use a >> column name (as defined by my Create Table) in a select statement, >> Rexx variables are set (using RexxSQL here) in the form >> x.columnname.n -- except if the column name used is OID, in which >> case the Rexx variable set is x.ROWID.n instead of the expected >> x.OID.n No mention is made in the documentation of this "quirk", >> which behavior is different from that of SQLite version 2. >> 2. *re integer vs string:* Version 3 differs from version 2 here. >> Version 2 was declared to be typeless and "Select Where column = >> 1" behaved identically with "Select Where column = '1'". Version >> 3 behavior is different in that the two previous examples produce >> different results, a compatibility issue. Version 3 documentation >> states that "SQLite may attempt to convert values between the >> numeric storage classes (INTEGER and REAL) and TEXT before >> performing a comparison." Apparently this is not done in the case >> of "Select Where column = '1'" and a particular row has been set >> with a value of unquoted 1. (Columns were defined with no type.) >> The v3 document (in discussing conversions) uses the expression >> "affinity is applied" without defining what that means. Does it >> mean "conversion to"? >> >> -R. >> >> D. Richard Hipp wrote: >> >>> On Sep 1, 2009, at 4:38 PM, Rod Dav4is wrote: >>> >>> >>> >>>> Aren't these problems considered worth fixing ? >>>> >>>> >>> I do not consider them to be problems. >>> >>> >>> >>>> Rod Dav4is wrote: >>>> >>>> >>>>> 1. *OID vs ROWID*: Specification of the OID field name (in >>>>> SELECT) >>>>> did not set Rexx variables X.OID.n, but instead set variables >>>>> x.ROWID.n >>>>> >>>>> >>> The "name" of a result column is undefined unless you use the "AS" >>> clause. We try to be reasonably consistent, but there are no >>> promises. There are especially no promises when moving form 2.8 to 3.6 >>> >>> >>> >>> >>>>> 2. *Quotes in SELECT*: Specification of Field='3' failed to find >>>>> hits; Field=3 (i.e. without quotes) was required. >>>>> >>>>> >>> This is a feature, not a bug. SQLite 3.x distinguishes between >>> integers and strings and does not consider them equal to one another. >>> You might have some rows where Field='3' and different rows where >>> Field=3 and SQLite will distinguish between them. >>> >>> D. Richard Hipp >>> d...@hwaci.com >>> >>> >>> >>> _______________________________________________ >>> sqlite-users mailing list >>> sqlite-users@sqlite.org >>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >>> >>> >>> >>> >> -- >> Regards, Rod Dav4is / P.O. Box 118 / Hyde Park, NY 12538 / USA >> Genealogy, et Cetera: http://freepages.rootsweb.ancestry.com/~dav4is/ >> 538 ancestral & collateral families, mostly 17°-19° century >> New England & European roots. Total population: 136,000+ >> Annex: http://www.gencircles.com/users/dav4is/ >> email: dav...@yahoo.com >> A Democrat, a Republican and a giraffe walk into a bar. The >> bartender looks up from his want ads and says, "What is this, a joke?" >> -unknown >> >> >> _______________________________________________ >> 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 > > >
-- Regards, Rod Dav4is / P.O. Box 118 / Hyde Park, NY 12538 / USA Genealogy, et Cetera: http://freepages.rootsweb.ancestry.com/~dav4is/ 538 ancestral & collateral families, mostly 17°-19° century New England & European roots. Total population: 136,000+ Annex: http://www.gencircles.com/users/dav4is/ email: dav...@yahoo.com A Democrat, a Republican and a giraffe walk into a bar. The bartender looks up from his want ads and says, "What is this, a joke?" -unknown _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
