Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

[Dominique Devienne]

On Thu, Sep 22, 2016 at 9:43 PM, Darren Duncan 
wrote:

> On 2016-09-22 12:16 PM, Petite Abeille wrote:
>
>>
>> On Sep 22, 2016, at 9:04 PM, Richard Hipp  wrote:
>>>
>>> (https://www.sqlite.org/draft/releaselog/3_15_0.html).
>>>
>>
>> Oh! Row Values! Nice! :)
>>
>> https://www.sqlite.org/draft/rowvalue.html
>>
>
> I second that, its a valuable feature to have.
>

For those interested, I ran by chance on this article that might have been
the origin of row values in SQLite:

From
http://use-the-index-luke.com/blog/2014-05/what-i-learned-about-sqlite-at-a-postgresql-conference
:

> We also discussed whether or not SQLite can cope with search conditions
> like(col1, col2) < (val1, val2)—it can’t.
> Here Richard was questioning the motivation to have that, so I gave him an
> elevator-pitch version of my
> “Pagination Done The PostgreSQL Way” talk. I think he got “excited” about
> this concept to avoid offset
> at all and I’m curious to see if he can make it work in SQLite faster than
> I’m adding SQLite content to Use The Index, Luke:)


That was 2 years ago :).--DD

PS: “Pagination Done The PostgreSQL Way” talk:
http://use-the-index-luke.com/blog/2013-07/pagination-done-the-postgresql-way
http://www.slideshare.net/MarkusWinand/p2d2-pagination-done-the-postgresql-way
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

[Dominique Devienne]

On Thu, Sep 29, 2016 at 2:37 PM, James K. Lowden 
wrote:

> On Fri, 23 Sep 2016 16:35:07 +
> Quan Yong Zhai  wrote:
>
> > Quote <<
> > A "row value" is an ordered list of two or more scalar values. In
> > other words, a "row value" is a vector.>>
> >
> > A ?row value? is a tuple, not a vector. When your using a tuple, you
> > know how many items in it, and the type of each item of it.
>
> That's correct, and addresses Dominique's point, albeit obliquely:
> to use a row-value as a list-argument to IN would be to confuse rows
> and columns.  A row-value has 1 or more columns, but only one row.
>
> It would be nice to use row-values correctly in IN:
>
> select * from T where (a,b) IN ( (1, 'a'), (2, 'b') )
>
> Is that valid?
>

After reading http://modern-sql.com/use-case/select-without-from
and given
http://sqlite.org/draft/rowvalue.html#search_against_multi_column_keys
it seems to me that it should be, albeit with this tiny variation:

  select * from T where (a,b) IN ( values (1, 'a'), (2, 'b') )

But not tested yet. --DD
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

[James K. Lowden]

On Fri, 23 Sep 2016 16:35:07 +
Quan Yong Zhai  wrote:

> Quote <<
> A "row value" is an ordered list of two or more scalar values. In
> other words, a "row value" is a vector.>>
> 
> A ?row value? is a tuple, not a vector. When your using a tuple, you
> know how many items in it, and the type of each item of it.

That's correct, and addresses Dominique's point, albeit obliquely:
to use a row-value as a list-argument to IN would be to confuse rows
and columns.  A row-value has 1 or more columns, but only one row.

It would be nice to use row-values correctly in IN:

select * from T where (a,b) IN ( (1, 'a'), (2, 'b') )

Is that valid? 

--jkl
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

[Simon Slavin]

On 26 Sep 2016, at 10:14pm, Richard Hipp  wrote:

> The first test failure cause the process to exit with a non-zero return code.

Good.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

[Richard Hipp]

On 9/26/16, Simon Slavin  wrote:
>
> On 26 Sep 2016, at 9:42pm, Richard Hipp  wrote:
>
>> Generates output: "testcase-100 ok".  Or, it generates an error
>> message if the expected result does not appear.
>
> Does it also change the exit code of the application ?  If it does then you
> can test the output in shell scripts and more easily use the CLI as part of
> a test suite.

The first test failure cause the process to exit with a non-zero return code.

>
> Or maybe it would be better to implement another dot command which
> immediately quit the CLI and returned a code indicating whether the previous
> output matched a GLOB value.
>
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>


-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

[Simon Slavin]

On 26 Sep 2016, at 9:42pm, Richard Hipp  wrote:

> Generates output: "testcase-100 ok".  Or, it generates an error
> message if the expected result does not appear.

Does it also change the exit code of the application ?  If it does then you can 
test the output in shell scripts and more easily use the CLI as part of a test 
suite.

Or maybe it would be better to implement another dot command which immediately 
quit the CLI and returned a code indicating whether the previous output matched 
a GLOB value.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

[Richard Hipp]

On 9/26/16, David Raymond  wrote:
> So the .help on .testcase says:
> .testcase NAME Begin redirecting output to 'testcase-out.txt'
>
> And .check says:
> .check GLOBFail if output since .testcase does not match

These dot-commands help in writing scripts that test various SQL
language features in SQLite.

For example, I could test various row-value comparisons using a script
like this:

.testcase 100
SELECT (1,2,3)<(1,2,4), (1,2,3)<(1,NULL,4), (1,2,3)<(2,NULL,1);
.check 1||1


Running that script using:

 ./sqlite3 http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

[David Raymond]

So the .help on .testcase says:
.testcase NAME Begin redirecting output to 'testcase-out.txt'

And .check says:
.check GLOBFail if output since .testcase does not match

So it's a way to check actual TEXT output vs expected TEXT output, right? Since 
I'm not sure of the normal reason for this I just played around with it real 
quick. Here're some tests where I don't know if it's working as intended or 
not. (For below copy/pastes headers default on) 


Windows 7 command prompt

sqlite_source_id()
2016-09-26 12:38:22 fe89225eab777c2c9cb1cbc31092b9e39f516842

--
.check on its own kills the session and quits back to the command prompt



D:\Temp>sqlite3
SQLite version 3.15.0 2016-09-26 12:38:22
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.

sqlite> .check
Usage: .check GLOB-PATTERN

D:\Temp>


--
Also kills the session if it fails the test.



D:\Temp>sqlite3
SQLite version 3.15.0 2016-09-26 12:38:22
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.

sqlite> create table tbl (a int, b text, c real);

sqlite> insert into tbl values (1, 'one', 1.0), (2, 'two', 2.0), (3, 'three', 
3.0);

sqlite> .testcase a

sqlite> select * from tbl where a = 1;

sqlite> .check 1|one|1.0
testcase-a FAILED
 Expected: [1|one|1.0]
  Got: [a|b|c
1|one|1.0
]

D:\Temp>


--
If testcase-out.txt exists from a previous session then .check looks at it even 
if you didn't do a .testcase on that session:



D:\Temp>sqlite3
SQLite version 3.15.0 2016-09-26 12:38:22
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.

sqlite> create table tbl (a int, b text, c real);

sqlite> insert into tbl values (1, 'one', 1.0), (2, 'two', 2.0), (3, 'three', 
3.0);

sqlite> .check a|b|c*
testcase- ok

sqlite>


--
Doing a .testcase immediately followed by a .check gives an error and quits to 
command prompt.



sqlite> .testcase b

sqlite> .check *
Error: cannot read 'testcase-out.txt'

D:\Temp>



--
Same thing happens if you do run queries but don't have any returned rows



D:\Temp>sqlite3
SQLite version 3.15.0 2016-09-26 12:38:22
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.

sqlite> create table tbl (a int, b text, c real);

sqlite> insert into tbl values (1, 'one', 1.0), (2, 'two', 2.0), (3, 'three', 
3.0);

sqlite> .testcase a

sqlite> select * from tbl where a = 4;

sqlite> .check *
Error: cannot read 'testcase-out.txt'

D:\Temp>



-Original Message-
From: David Raymond 
Sent: Friday, September 23, 2016 12:57 PM
To: 'SQLite mailing list'
Subject: RE: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

-Add the ".testcase" and ".check" dot-commands.

Is there documention on what these are? I don't see anything on them in the 
linked CLI page draft.
https://www.sqlite.org/draft/cli.html

-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of Richard Hipp
Sent: Thursday, September 22, 2016 3:04 PM
To: General Discussion of SQLite Database
Subject: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

Our current schedule for the next SQLite release (3.15.0) is for 2016-10-14.

Your beta-tests are appreciated.  You can get a pre-release snapshot
from the download page (https://www.sqlite.org/download.html) and you
can review the change log
(https://www.sqlite.org/draft/releaselog/3_15_0.html).

The trunk (https://www.sqlite.org/src/timeline?r=trunk) is stable and
is being used by the SQLite developers for mission-critical processes.

Thank you for your attention.
-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

[Simon Slavin]

> On 26 Sep 2016, at 7:48pm, Warren Young  wrote:
> 
>> ​What can I do to beta test?

The other part of the question is "How do I download the beta-test version in 
order to beta-test it ?".

For technical reasons, the download page in the /draft/ version of the web site 
doesn't actually include download links.  The pre-release version can be found 
in the yellow portion at the top of this page:



While I'm here, I note that



does not include documentation for the two newly-introduced dot commands.  I 
think someone else noted this too but I can't find the post at the moment.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

[Warren Young]

On Sep 25, 2016, at 4:50 AM, Cecil Westerhof  wrote:
> 
> 2016-09-22 21:04 GMT+02:00 Richard Hipp :
> 
>> Our current schedule for the next SQLite release (3.15.0) is for
>> 2016-10-14.
>> 
>> Your beta-tests are appreciated.
> 
> ​What can I do to beta test?

First, just try it against your existing application, to see if there are any 
regressions.

Second, go through the changelog and see if there are any new features or fixes 
that interest you:

  https://www.sqlite.org/draft/releaselog/current.html
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

[Cecil Westerhof]

2016-09-22 21:04 GMT+02:00 Richard Hipp :

> Our current schedule for the next SQLite release (3.15.0) is for
> 2016-10-14.
>
> Your beta-tests are appreciated.


​What can I do to beta test?

-- 
Cecil Westerhof
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

[David Raymond]

-Add the ".testcase" and ".check" dot-commands.

Is there documention on what these are? I don't see anything on them in the 
linked CLI page draft.
https://www.sqlite.org/draft/cli.html

-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of Richard Hipp
Sent: Thursday, September 22, 2016 3:04 PM
To: General Discussion of SQLite Database
Subject: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

Our current schedule for the next SQLite release (3.15.0) is for 2016-10-14.

Your beta-tests are appreciated.  You can get a pre-release snapshot
from the download page (https://www.sqlite.org/download.html) and you
can review the change log
(https://www.sqlite.org/draft/releaselog/3_15_0.html).

The trunk (https://www.sqlite.org/src/timeline?r=trunk) is stable and
is being used by the SQLite developers for mission-critical processes.

Thank you for your attention.
-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

[Gerry Snyder]

Just curious--will Tcl lists be usable as row values?

Gerry Snyder

On Thu, Sep 22, 2016 at 12:04 PM, Richard Hipp  wrote:

> Our current schedule for the next SQLite release (3.15.0) is for
> 2016-10-14.
>
> Your beta-tests are appreciated.  You can get a pre-release snapshot
> from the download page (https://www.sqlite.org/download.html) and you
> can review the change log
> (https://www.sqlite.org/draft/releaselog/3_15_0.html).
>
> The trunk (https://www.sqlite.org/src/timeline?r=trunk) is stable and
> is being used by the SQLite developers for mission-critical processes.
>
> Thank you for your attention.
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

[Quan Yong Zhai]

http://sqlite.org/draft/rowvalue.html

Quote<<

A "row value" is an ordered list of two or more scalar values. In other words, 
a "row value" is a vector.>>



some word in the above sentence not strictly correct. A “row value” is a tuple, 
not a vector. When your using a tuple, you know how many items in it, and the 
type of each item of it.



Like “SELECT * FROM CUSTOMER WHERE (first_name, last_name, birthday) = ( :1, 
:2, :3)”

Obviously, LHS and RHS is a tuple, sqlite3_bind_values() is not needed for 
above SQL statements.



A vector is an arbitrary length of elements of same type.

Like “SELECT * FROM CUSTOMER WHERE CUST_ID  IN (?, ?, ?, ? ….)”



What you need is sqlite3_bind_vector(), And that’s carray extension work for, 
simple modify a few lines, it will support blobs or your custom type. I don’t 
think a dedicated sqlite3_bind_values() or sqlite3_bind_vector() worth the 
effort.



Zhai



Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10



From: Dominique Devienne<mailto:ddevie...@gmail.com>
Sent: 2016年9月23日 23:29
To: SQLite mailing list<mailto:sqlite-users@mailinglists.sqlite.org>
Subject: Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14



On Fri, Sep 23, 2016 at 5:04 PM, Keith Medcalf <kmedc...@dessus.com> wrote:

> [...] bind the RHS of a IN operator of arbitrary size [...]
>
> A carray won't work for you?


No. carray doesn't support blobs.

The semantic of carray is fundamentally flawed for variable-sized values.
And the lifetime management, or lack thereof, is also fundamentally flawed.

Binding is about providing explicit values to a compiled statement.

Binding a surrogate (a raw pointer...) to those values, to a table-valued
function,
which further assumes a given representation in memory, which for char*
implies
an indirection to some other memory slots which must be null-terminated,
that's
all very "icky" IMHO, and most unlike SQLite's usual clean designs.

My proposed sqlite3_bind_row_value() is I think much closer to SQLite's
norm. FWIW. --DD
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

[Dominique Devienne]

On Fri, Sep 23, 2016 at 5:04 PM, Keith Medcalf  wrote:

> [...] bind the RHS of a IN operator of arbitrary size [...]
>
> A carray won't work for you?


No. carray doesn't support blobs.

The semantic of carray is fundamentally flawed for variable-sized values.
And the lifetime management, or lack thereof, is also fundamentally flawed.

Binding is about providing explicit values to a compiled statement.

Binding a surrogate (a raw pointer...) to those values, to a table-valued
function,
which further assumes a given representation in memory, which for char*
implies
an indirection to some other memory slots which must be null-terminated,
that's
all very "icky" IMHO, and most unlike SQLite's usual clean designs.

My proposed sqlite3_bind_row_value() is I think much closer to SQLite's
norm. FWIW. --DD
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

[Keith Medcalf]

> For a long time, I've wanted to bind the RHS of a IN operator of arbitrary
> size,
> instead of
> 1) having to hard-code the cardinality, e.g. IN (:1, :2);
> 2) or use a tmp table to insert the values and use a subquery;
> 3) somehow use an eponymous vtable as the RHS.
> 
> None of which is very clean or satisfying.
> Any chance this could be finally cleaned up by binding a row value
> instead?
> --DD

A carray won't work for you?




___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

[Dominique Devienne]

On Fri, Sep 23, 2016 at 1:39 PM, Richard Hipp  wrote:

> On 9/23/16, Dominique Devienne  wrote:
> >
> > For a long time, I've wanted to bind the RHS of a IN operator of
> arbitrary size,
>
> See the carray() table-valued function extension:
> https://www.sqlite.org/draft/carray.html


Thanks for the reminder.

My RHS is a list of guids in the form of blob(16) values, so carray doesn't
fit.
I can of course make my own carray-like eponymous vtable, but honestly
passing
a pointer to an array who's lifetime is not managed by SQLite is a hack
IMHO.

This is what I wish for:

sqlite3_bind_row_value( // or sqlite3_bind_array, either way
  sqlite3_stmt*,
  int, // bind index
  void *pApp, // access via sqlite3_user_data(), and passed in to callbacks
below
  int (*xSize)(sqlite3_context*, void* pApp), // optional? but if provided,
used by query planner
  int (*xItem)(sqlite3_context*, void* pApp), // returns SQLITE_OK or
SQLITE_DONE (unless xSize required)
  void(*xDestroy)(void* pApp)
);

This is like an "anonymous" "eponymous" "temporary" vtable, whose lifetime
is managed
by SQLite properly. It's a cross between a sqlite3_bind_* and
sqlite3_register_*, and the
sqlite3_context* allows to return one value at a time, with an optional
cardinality method
to allow the query planner to use the best plan, but w/o the
sqlite3_value** argument
since binding does not depend on runtime arguments.

And by reusing the machinery of https://www.sqlite.org/c3ref/context.html,
we can even leverage the recent
https://www.sqlite.org/c3ref/result_subtype.html too.

AFAIK, this is much easier than eponymous vtables, but more importantly
it is safe, clean, with proper (temporary) lifetime semantics, and
anonymous too.

My $0.02. --DD
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

[Richard Hipp]

On 9/23/16, Dominique Devienne  wrote:
>
> For a long time, I've wanted to bind the RHS of a IN operator of arbitrary
> size,

See the carray() table-valued function extension:
https://www.sqlite.org/draft/carray.html

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

[R Smith]

On 2016/09/22 9:04 PM, Richard Hipp wrote:

Our current schedule for the next SQLite release (3.15.0) is for 2016-10-14.



   2.2. Row Values In UPDATE Statements

Row values can also be used in the SET clause of an UPDATE 
 statement. The RHS must 
be a list of column names. The LHS can be any row value. For example:


UPDATE tab3
   SET (a,b,c) = (SELECT x,y,z
FROM tab4
   WHERE tab4.w=tab3.d);
 WHERE tab3.e BETWEEN 55 AND 66;


 That's an answered need if ever I saw one - Much appreciation!!
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

[Clemens Ladisch]

Petite Abeille wrote:
> Oh! Row Values! Nice! :)


This description exchanges "LHS" and "RHS".


Regards,
Clemens
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

[Dominique Devienne]

On Thu, Sep 22, 2016 at 9:04 PM, Richard Hipp  wrote:

> Our current schedule for the next SQLite release (3.15.0) is for
> 2016-10-14.
> [...] you can review the change log
> (https://www.sqlite.org/draft/releaselog/3_15_0.html).



> SQLite Release 3.15.0 (Pending)
>
> Added support for row values.
>

https://www.sqlite.org/draft/rowvalue.html

When do we get to bind row values?

For a long time, I've wanted to bind the RHS of a IN operator of arbitrary
size,
instead of
1) having to hard-code the cardinality, e.g. IN (:1, :2);
2) or use a tmp table to insert the values and use a subquery;
3) somehow use an eponymous vtable as the RHS.

None of which is very clean or satisfying.
Any chance this could be finally cleaned up by binding a row value instead?
--DD
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

[James K. Lowden]

On Thu, 22 Sep 2016 12:43:29 -0700
Darren Duncan  wrote:

> single-element row could be done with say a trailing comma; eg
> "(42,)" 

All hail the Python tuple!  

"Tuples of two or more items are formed by comma-separated
lists of expressions. A tuple of one item (a ?singleton?) can be formed
by affixing a comma to an expression (an expression by itself does not
create a tuple, since parentheses must be usable for grouping of
expressions). An empty tuple can be formed by an empty pair of
parentheses."

https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy

--jkl


  
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

[Darren Duncan]

On 2016-09-22 12:16 PM, Petite Abeille wrote:



On Sep 22, 2016, at 9:04 PM, Richard Hipp  wrote:

(https://www.sqlite.org/draft/releaselog/3_15_0.html).


Oh! Row Values! Nice! :)

https://www.sqlite.org/draft/rowvalue.html


I second that, its a valuable feature to have.

The purist in me thinks it should also be possible to have rows with exactly 1 
or zero elements also, not just 2+ as described above.


Syntactically, () could be a zero-element row, and distinguishing a 
single-element row could be done with say a trailing comma; eg "(42,)" is a 
single-element row while "(42)" is simply the value 42 since parens are also 
used for forcing evaluation precedence of expressions.


-- Darren Duncan

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

[Petite Abeille]

> On Sep 22, 2016, at 9:04 PM, Richard Hipp  wrote:
> 
> (https://www.sqlite.org/draft/releaselog/3_15_0.html).

Oh! Row Values! Nice! :)

https://www.sqlite.org/draft/rowvalue.html



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users