Darren Duncan <[EMAIL PROTECTED]> wrote:
> At 7:05 PM -0500 3/12/06, [EMAIL PROTECTED] wrote:
> >Let me amplify this by pointing out that I have zero interest
> >in taking SQLite in the direction of The Third Manifesto. Those
> >who want to do so are welcomed - encouraged even - to fork the
>
At 7:05 PM -0500 3/12/06, [EMAIL PROTECTED] wrote:
Let me amplify this by pointing out that I have zero interest
in taking SQLite in the direction of The Third Manifesto. Those
who want to do so are welcomed - encouraged even - to fork the
tree and go off in their own direction. Just do not
Joe Wilson <[EMAIL PROTECTED]> wrote:
>
> If some people wish to pursue writing The Third Manifesto or some
> other SQL-derivative work, they should consider making a new
> SourceForge project of it (or whatever). Debating its merits here
> is offtopic to SQLite.
>
Let me amplify this by
"K. Haley" <[EMAIL PROTECTED]> wrote:
> >
> > But its worse than that, in that SQL isn't even consistent with itself
> > in how it treats nulls. With some kinds of operations or queries, it
> > treats every null being unique, and in other situations it treats them
> > all as being equal. No
reer in regards to
application of relational database technology.
Fred
> -Original Message-
> From: Joe Wilson [mailto:[EMAIL PROTECTED]
> Sent: Sunday, March 12, 2006 11:03 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] updating SQLite to implement The Third Manifesto
>
&
You can model NULL with the creation of a few more tables
listing the rows in which information is absent. But why should
you create more work for yourself? People find SQL to be useful in
its present form - NULLs and all. It is a fairly standard and well
known thing.
If some people wish to
Darren Duncan wrote:
>> I never understood that restriction. I read in the books: "since we
>> have defined things this ways from a formal point of view there's no
>> room for NULL". And my question is well, why don't you change the
>> definitions to augment the datatype sets with a special
Note: This email is a combined reply to several other emails in the
same thread.
At 12:32 AM -0600 3/11/06, Marian Olteanu wrote:
You're right Darren, but the problem is that we're not in a DB class. We
cannot tell people who have a solution for their problems that "your
solution is wrong. You
On Sat, 11 Mar 2006, ThomasChust wrote:
[...]
as the author of yet another SQLite3 binding for a manifestly typed language
(CHICKEN Scheme) I can only second the concerns expressed in other answers to
the original posting. I would expect the interface to get far more
complicated with strict
Hello,
as the author of yet another SQLite3 binding for a manifestly typed
language (CHICKEN Scheme) I can only second the concerns expressed in
other answers to the original posting. I would expect the interface to get
far more complicated with strict typing in SQLite3. In fact, that SQLite3
On Mar 11, 2006, at 7:58, Andrew Piskorski wrote:
On Fri, Mar 10, 2006 at 04:37:36PM -0800, Darren Duncan wrote:
3. There is no such thing as a NULL.
3.1 All logic is 2VL (true, false) not 3VL (true, false, unknown).
There is no such thing as null, really? So, when you do an outer join
On Fri, Mar 10, 2006 at 04:37:36PM -0800, Darren Duncan wrote:
> 3. There is no such thing as a NULL.
>
> 3.1 All logic is 2VL (true, false) not 3VL (true, false, unknown).
There is no such thing as null, really? So, when you do an outer join
between two tables, which in SQL would produce
] updating SQLite to implement The Third Manifesto
At 6:52 PM -0800 3/10/06, Roger Binns wrote:
>Only for some applications. It would be harder to use for
>my apps. Specifically manifest typing as currently implemented
>in SQLite is a perfect match for apps writen in Python (which
>als
Just for the record:
it wouldn't require any significant amount more code.
Yes it would. My code currently approximates to this:
cursor.execute("insert into foo (x,y,z) values(?,?,?)", x,y,z)
It would have to change into this:
# column x is defined as string
if isinstance(x, string):
At 6:52 PM -0800 3/10/06, Roger Binns wrote:
Only for some applications. It would be harder to use for
my apps. Specifically manifest typing as currently implemented
in SQLite is a perfect match for apps writen in Python (which
also uses manifest typing). It would require a lot more code
to
In doing all of the above, SQLite should actually be simpler to
implement, and it will be easier to use, with more predictable
results and fewer bugs.
Only for some applications. It would be harder to use for
my apps. Specifically manifest typing as currently implemented
in SQLite is a
All, and particularly Dr. Hipp,
Lately, my own database project in Perl, named Rosetta, has evolved
to officially be an implementation of Chris Date's and Hugh Darwen's
proposal for relational databases called "The Third Manifesto", which
is talked about at http://www.thethirdmanifesto.com/
17 matches
Mail list logo
