> On Tue, Feb 4, 2020 at 5:38 PM Doug wrote:
> > > You're twisting my point here. I obviously want the reverse,
> > > I want the database types to "drive" the binding done. 1-to-1.
> > > Because even if binding a different type would work, via
> SQLite's
> > > own implicit conversion, I don't
On Tue, Feb 4, 2020 at 5:38 PM Doug wrote:
> > You're twisting my point here. I obviously want the reverse,
> > I want the database types to "drive" the binding done. 1-to-1.
> > Because even if binding a different type would work, via SQLite's
> > own implicit conversion, I don't want that,
> You're twisting my point here. I obviously want the reverse,
> I want the database types to "drive" the binding done. 1-to-1.
> Because even if binding a different type would work, via SQLite's
> own implicit conversion, I don't want that, because it's hiding a
> bug in the code most likely
On Mon, Feb 3, 2020 at 6:42 PM James K. Lowden wrote:
> Do you want to force applications to "pre-convert" values the DBMS can
> convert implicitly?
Yes, that's exactly what I want James.
I want the enforce the bind-value type to be an exact match for the
column value type.
I could before, via
> You say that you want to prevent the use of the string literal '123'
> for inserting into the integer field x. That will no longer be
> possible in SQLite beginning with 3.32.0 (assuming the change
> currently on trunk goes through.)
> But, why do you want to do that?
You are right. I
On Mon, 3 Feb 2020 10:45:50 +0100
Dominique Devienne wrote:
> On Sun, Feb 2, 2020 at 12:50 AM Richard Hipp wrote:
>
> > On 2/1/20, Thomas Kurz wrote:
> > > Does this mean there will be no possibility to prevent inserting
> > > a string into an integer column anymore?
> > >
> > > create table
On Mon, Feb 3, 2020 at 5:35 PM Richard Hipp wrote:
> On 2/3/20, Dominique Devienne wrote:
> > On Sun, Feb 2, 2020 at 12:50 AM Richard Hipp wrote:
>
> This is the SQL:
>
> CREATE TABLE t1(x INT CHECK(typeof(x)=='integer'));
> INSERT INTO t1(x) VALUES('123');
>
> You say that you want to
On 2/3/20, Dominique Devienne wrote:
> On Sun, Feb 2, 2020 at 12:50 AM Richard Hipp wrote:
>
>> On 2/1/20, Thomas Kurz wrote:
>> >
>> > create table x (x integer check (typeof(x) == 'integer'));
>> > insert into x values ('1');
>> >
>> > --> will pass in future versions???
>>
>> I think that is
On Sun, Feb 2, 2020 at 12:50 AM Richard Hipp wrote:
> On 2/1/20, Thomas Kurz wrote:
> > Does this mean there will be no possibility to prevent inserting a string
> > into an integer column anymore?
> >
> > create table x (x integer check (typeof(x) == 'integer'));
> > insert into x values
On 2/2/20, Thomas Kurz wrote:
> And are there any consequences for something like
>
>> create table x (x text check (typeof(x) == 'text'));
>> insert into x values ('1');
>
Not that I know of.
--
D. Richard Hipp
d...@sqlite.org
___
sqlite-users
And are there any consequences for something like
> create table x (x text check (typeof(x) == 'text'));
> insert into x values ('1');
?
- Original Message -
From: Richard Hipp
To: SQLite mailing list
Sent: Sunday, February 2, 2020, 00:50:34
Subject: [sqlite] Check constrain
On 2/1/20, Thomas Kurz wrote:
> Does this mean there will be no possibility to prevent inserting a string
> into an integer column anymore?
>
> create table x (x integer check (typeof(x) == 'integer'));
> insert into x values ('1');
>
> --> will pass in future versions???
I think that is what it
Does this mean there will be no possibility to prevent inserting a string into
an integer column anymore?
create table x (x integer check (typeof(x) == 'integer'));
insert into x values ('1');
--> will pass in future versions???
- Original Message -
From: Richard Hipp
To: SQLite
On 1/31/20, Keith Medcalf wrote:
>
> That would elevate this to the status of a bug since it should be impossible
> to do this.
>
It is also not something that is fixable, so the solution will likely
be to simply document it.
--
D. Richard Hipp
d...@sqlite.org
On Friday, 31 January, 2020 14:39, Simon Slavin wrote:
>On 31 Jan 2020, at 9:27pm, Keith Medcalf wrote:
>> You are however correct that this is an "application consistency"
>problem more than an SQLite problem and it is a lot of change for little
>actual benefit.
>How about this ?
>A
15 matches
Mail list logo