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
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
On 1 Jul 2010, at 2:21pm, Pavel Ivanov wrote:
CREATE TABLE X as SELECT...
syntax ought not to produce a table with an INT primary key if the prototype
had INTEGER.
The problem is not with primary keys, it's with the types of the columns in the
table. The command is not
CREATE TABLE y AS
This is obviously wrong. The SELECT command from TABLE t could never have
returned any INT values (because SQLite has no INT datatype). So why was
TABLE t_copy created with an INT column ?
Because three letters INT are enough to assign INTEGER affinity to the column.
From
Here is what I wrote to Jay earlier this morning but meant to send to the
entire list. I am still in the habit of hitting Reply in Google Mail when I
should be hitting a different button that also says Reply.
sent earlier today to Jay
Jay,
I agree with 99.44% of what you say. If in the future
On 1 Jul 2010, at 2:49pm, Pavel Ivanov wrote:
This is obviously wrong. The SELECT command from TABLE t could never have
returned any INT values (because SQLite has no INT datatype). So why was
TABLE t_copy created with an INT column ?
Because three letters INT are enough to assign
There is no such datatype as 'INT' in SQLite. No part of SQLite should be
declaring /any/ column as having an affinity of 'INT'.
Yet another holly war and another fake problem... :(
Why SQLite shouldn't declare column as INT? Who is confused by that
this time? Yes, I know that there's no data
Thanks Tim for taking the time to point this out.
On 1 July 2010 13:41, 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
On Thu, Jul 01, 2010 at 03:44:52PM +0100, Simon Slavin scratched on the wall:
There is no such datatype as 'INT' in SQLite.
SQLite doesn't have defined datatypes, so I suppose you could say
this is correct. But if you want to say that SQLite has no 'INT'
datatype, it is just as legit
Puneet,
I am simply pointing out a potential pitfall. Putting up a highway sign
that says Soft Shoulder is one way to go about things. Widening the
shoulder and perhaps paving it is another.
Regards
Tim Romano
Swarthmore PA
On Tue, Jun 29, 2010 at 11:56 AM, P Kishor punk.k...@gmail.com wrote:
Jay,
Let me try to scratch on the wall one more time and perhaps my point will
make its way through.
Notwithstanding your insistence that INT and INTEGER are the same in SQLite,
*with respect to use in the PRIMARY KEY definition* there are subtle
differences. In the authoritative version of
On Wed, 2010-06-30 at 09:04 -0400, Tim Romano wrote:
snip
The EXAMPLE: If you create a database in the authoritative version of SQLite
using INT PRIMARY KEY (rather than INTEGER PRIMARY KEY), when you share the
database with your Adobe-using affiliate, all hell will break loose. I will
On Wed, Jun 30, 2010 at 09:04:14AM -0400, Tim Romano scratched on the wall:
Notwithstanding your insistence that INT and INTEGER are the same in SQLite,
*with respect to use in the PRIMARY KEY definition* there are subtle
differences.
Yes. However, CREATE TABLE ... AS SELECT doesn't carry
CREATE TABLE main.proto (id INTEGER PRIMARY KEY AUTOINCREMENT NOT
NULL , name TEXT)
CREATE TABLE main.clone as select * from PROTO
The primary key of table CLONE is defined as INT not INTEGER.
Regards
Tim Romano
Swarthmore PA
___
sqlite-users
On Tue, Jun 29, 2010 at 06:59:18AM -0400, Tim Romano scratched on the wall:
CREATE TABLE main.proto (id INTEGER PRIMARY KEY AUTOINCREMENT NOT
NULL , name TEXT)
CREATE TABLE main.clone as select * from PROTO
The primary key of table CLONE is defined as INT not INTEGER.
The only
...which actually surprises me, since I was under the impression
CREATE TABLE ... AS SELECT always produced NONE affinities. Is this
a semi-recent (last year) change?
It looks like the only recent change was a year ago:
http://www.sqlite.org/changes.html#version_3_6_15.
But according to
But there may be an argument for making the cloning more precise. It's a
bit of a mess, or at least it seems so to me because my first ten years of
database work was done with PICK, a database that was developed by PICK
Systems but licensed to many companies and marketed under different brands
On Tue, Jun 29, 2010 at 9:58 AM, Tim Romano tim.romano...@gmail.com wrote:
But there may be an argument for making the cloning more precise.
The issue is that CREATE TABLE t AS SELECT... is not meant to clone a
table. Not too long ago I encountered the same issue (search the mail
archives).
I think
SQLite implementations should probably adhere to a core spec but I recognize
this as my bias, not dogma.
Probably this is my personal opinion but why should SQLite comply with
specification of Pick Multi-dimensional databases if it never claimed
to be multi-dimensional? SQLite is a
Puneet,
I am not trying to give Adobe any sort of primacy; but I wouldn't call them
unimportant either.
The core concern, at least as I see it, is the undesirable effects of
sharing data between implementations that do not handle INT and INTEGER
primary keys compatibly.
I don't use and won't
On Tue, Jun 29, 2010 at 10:46 AM, Tim Romano tim.romano...@gmail.com wrote:
Puneet,
I am not trying to give Adobe any sort of primacy; but I wouldn't call them
unimportant either.
The core concern, at least as I see it, is the undesirable effects of
sharing data between implementations that
Pavel,
As I said, I am biased in favor of the benefits to there being
core-compatibility among the various implementations of SQLite but I am not
dogmatic about it, and I have no say in the matter in any case ;-)
But I think you may have misunderstood me: I am not arguing that SQlite
should be
On Tue, Jun 29, 2010 at 11:46:34AM -0400, Tim Romano scratched on the wall:
The core concern, at least as I see it, is the undesirable effects of
sharing data between implementations that do not handle INT and INTEGER
primary keys compatibly.
The only known program that can read SQLite
On Tue, Jun 29, 2010 at 11:46 AM, Tim Romano tim.romano...@gmail.comwrote:
Here's a little story:
The Therac-25. http://sunnyday.mit.edu/papers/therac.pdf
--
-
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
PICK is simply an
example of a database that came in many slightly different versions all of
which adhered to a core definition, and this compatibility was a good
thing.
Then I reiterate my point using your wordings: SQL comes in different
versions and flavors (SQLite, Oracle, MS SQL etc.)
On Tue, Jun 29, 2010 at 09:51:42AM -0400, Pavel Ivanov scratched on the wall:
?...which actually surprises me, since I was under the impression
?CREATE TABLE ... AS SELECT always produced NONE affinities. ?Is this
?a semi-recent (last year) change?
It looks like the only recent change was
26 matches
Mail list logo
