Jose Isaias Cabrera, on Friday, May 17, 2019 08:28 AM, wrote...
>J. King, on Friday, May 17, 2019 07:19 AM, wrote...
>>Perhaps I should have been clearer that this is a regression?
>>
I know, overkill, but here is another look at it,
SQLite version 3.28.0 2019-04-16 19:49:53
Enter ".help" for
Simon Slavin wrote:
> On 17 May 2019, at 1:33pm, Clemens Ladisch wrote:
>> This keyword behaves magically.
... as far as the SQL standard is concerned.
> Mmmm. In that case, to implement this properly you need to store
> a default-type flag alongside the default value.
The SQLite syntax
On 17 May 2019, at 1:33pm, Clemens Ladisch wrote:
> This keyword behaves magically.
Mmmm. In that case, to implement this properly you need to store a
default-type flag alongside the default value. Proposed values might be
0) No default specified, so use …
1) Fixed default specified, so use
Simon Slavin wrote:
> If you supply "default CURRENT_TIMESTAMP" I would expect SQLite to
> evaluate CURRENT_TIMESTAMP, find a string value like
> '2019-05-17 12:10:43', and store that string in the schema.
This keyword behaves magically. ANSI SQL-92 says:
| The default value inserted in the
J. King, on Friday, May 17, 2019 07:19 AM, wrote...
>Perhaps I should have been clearer that this is a regression?
>
>SQLite version 3.13.0 2016-05-18 10:57:30
>Enter ".help" for usage hints.
>Connected to a transient in-memory database.
>Use ".open FILENAME" to reopen on a persistent database.
Please disregard, apologies for the noise.
From: "Nelson, Erik - 2"
Sent: May 17, 2019 8:17 AM
To: sqlite-users@mailinglists.sqlite.org
Subject: [External email from sqlite-users-boun...@mailinglists.sqlite.org] Re:
[sqlite] Bug in table_info pragm
We need to get these into the hive database, if that's helpful
From: Simon Slavin
Sent: May 17, 2019 8:16 AM
To: SQLite mailing list
Subject: Re: [sqlite] Bug in table_info pragma
On 17 May 2019, at 12:06pm, J. King wrote:
> Then there wo
On 17 May 2019, at 12:06pm, J. King wrote:
> Then there would be no differentiating "default CURRENT_TIMESTAMP" from
> "default 'CURRENT_TIMESTAMP'".
That interesting.
If you supply "default CURRENT_TIMESTAMP" I would expect SQLite to evaluate
CURRENT_TIMESTAMP, find a string value like
On 2019-05-17 07:08:27, "Warren Young" wrote:
On May 17, 2019, at 4:55 AM, J. King wrote:
SQLite version 3.28.0 2019-04-16 19:49:53
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> create table
On May 17, 2019, at 4:55 AM, J. King wrote:
>
> SQLite version 3.28.0 2019-04-16 19:49:53
> Enter ".help" for usage hints.
> Connected to a transient in-memory database.
> Use ".open FILENAME" to reopen on a persistent database.
> sqlite> create table t(a text default '' /* comment */ );
>
On 2019-05-17 06:59:58, "Simon Slavin" wrote:
On 17 May 2019, at 11:55am, J. King wrote:
I would expect it to print only the string delimiters.
I might expect it to print only the thing inside the delimiters, i.e. nothing.
Then there would be no differentiating "default
On 17 May 2019, at 11:55am, J. King wrote:
> I would expect it to print only the string delimiters.
I might expect it to print only the thing inside the delimiters, i.e. nothing.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
SQLite version 3.28.0 2019-04-16 19:49:53
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> create table t(a text default '' /* comment */ );
sqlite> select dflt_value from pragma_table_info('t') where name
13 matches
Mail list logo
