On 10/13/19, Shawn Wagner wrote:
> The documentation for a column with NUMERIC affinity says
>
>> When text data is inserted into a NUMERIC column, the storage class of
> the text is converted to INTEGER or REAL (in order of preference) if such
> conversion is lossless and reversible.
>
Thank you
On 10/13/2019 8:04 PM, Shawn Wagner wrote:
That's what I told the guy having the original issue to do, yes. That's not
important.
My concern is why a conversion that's only supposed to happen if it's
lossless is in fact happening and causing data loss.
You define the term "lossless" differentl
That's what I told the guy having the original issue to do, yes. That's not
important.
My concern is why a conversion that's only supposed to happen if it's
lossless is in fact happening and causing data loss.
On Sun, Oct 13, 2019, 4:48 PM Igor Tandetnik wrote:
> On 10/13/2019 7:25 PM, Shawn Wa
On 10/13/2019 7:25 PM, Shawn Wagner wrote:
I wouldn't call that conversion, or any other, lossless unless it can be
turned back into a string that's character for character identical with the
one that was originally inserted.
If you want the text preserved character for character, store it in a
e's a Highway to Hell but only a Stairway to Heaven says a
lot about anticipated traffic volume.
>-Original Message-
>From: sqlite-users On
>Behalf Of Shawn Wagner
>Sent: Sunday, 13 October, 2019 17:26
>To: SQLite mailing list
>Subject: Re: [sqlite] Possible bug i
On October 13, 2019 7:25:50 p.m. EDT, Shawn Wagner
wrote:
>I wouldn't call that conversion, or any other, lossless unless it can
>be
>turned back into a string that's character for character identical with
>the
>one that was originally inserted.
It's lossless if you consider the input as the num
Yes, I know. (This all comes from someone on stack overflow who used
"string" as a column type and thus ran into this issue because that of
course results in numeric affinity)
On Sun, Oct 13, 2019, 4:27 PM Simon Slavin wrote:
> On 13 Oct 2019, at 10:11pm, Shawn Wagner wrote:
>
> > As you can se
On 13 Oct 2019, at 10:11pm, Shawn Wagner wrote:
> As you can see, the leading zeros in the original string are gone and it's
> been converted to an integer. This seems to violate the "lossless and
> reversible" constraint. Shouldn't it be kept as text?
You defined the column as 'numeric'. Had
I wouldn't call that conversion, or any other, lossless unless it can be
turned back into a string that's character for character identical with the
one that was originally inserted.
On Sun, Oct 13, 2019, 4:10 PM Igor Tandetnik wrote:
> On 10/13/2019 5:11 PM, Shawn Wagner wrote:
> > The document
On 10/13/2019 5:11 PM, Shawn Wagner wrote:
The documentation for a column with NUMERIC affinity says
When text data is inserted into a NUMERIC column, the storage class of
the text is converted to INTEGER or REAL (in order of preference) if such
conversion is lossless and reversible.
"Lossle
3.30, though it goes back to at least 3.8.7 (the oldest version I have
available to test with)
On Sun, Oct 13, 2019, 3:03 PM Igor Korot wrote:
> Hi,
>
> On Sun, Oct 13, 2019 at 4:12 PM Shawn Wagner
> wrote:
> >
> > The documentation for a column with NUMERIC affinity says
> >
> > > When text da
Hi,
On Sun, Oct 13, 2019 at 4:12 PM Shawn Wagner wrote:
>
> The documentation for a column with NUMERIC affinity says
>
> > When text data is inserted into a NUMERIC column, the storage class of
> the text is converted to INTEGER or REAL (in order of preference) if such
> conversion is lossless a
The documentation for a column with NUMERIC affinity says
> When text data is inserted into a NUMERIC column, the storage class of
the text is converted to INTEGER or REAL (in order of preference) if such
conversion is lossless and reversible.
But consider:
sqlite> create table foo(bar numeric);
13 matches
Mail list logo
