Would dropping the non-functioning default clause from the schema be a
"breaking change"?
That is from:
# sqlite3 dummy.db
sqlite> CREATE TABLE x(
...> id INTEGER PRIMARY KEY DEFAULT (random()),
...> val VARCHAR
...> );
sqlite> .schema
CREATE TABLE x(
*id INTEG
On Thu, Sep 25, 2014 at 4:46 PM, Mark Lawrence wrote:
>
> If you are going to keep this behaviour would it not make more sense to
> ensure that the table creation fails? The DEFAULT clause is pretty
> straight-forward and I don't find it intuitive to go looking for
> PRIMARY KEY documentation whe
On Thu Sep 25, 2014 at 03:59:55PM -0400, Richard Hipp wrote:
>
> I will make an effort to clarify this in the documentation.
If you are going to keep this behaviour would it not make more sense to
ensure that the table creation fails? The DEFAULT clause is pretty
straight-forward and I don't find
On Thu, Sep 25, 2014 at 3:30 PM, Mark Lawrence wrote:
>
> I understand that that behaviour exists and applies when an insert does
> not provide a value, but I don't see the contradiction. The table
> defines an *explicit* default that should (to my mind) override any
> kind of magical-in-the-abse
On Thu Sep 25, 2014 at 03:18:04PM -0400, Adam Devita wrote:
> Your table definition seems to have a contradiction. The expression
> INTEGER PRIMARY KEY is a special keyword that means 'auto-increment',
> which would be a default value.
I understand that that behaviour exists and applies when an
Your table definition seems to have a contradiction.
The expression INTEGER PRIMARY KEY is a special keyword that means
'auto-increment', which would be a default value. DEFAULT (random() )
would contradict the auto-increment instruction. The row id was being used
to generate the key.
On Thu,
Plan:
CREATE TABLE x(
id INTEGER PRIMARY KEY DEFAULT (random()),
val VARCHAR
);
INSERT INTO x(val) VALUES ('a');
SELECT * FROM x;
Result:
id val
-- --
1 a
Expected result:
id
7 matches
Mail list logo
