On Wed, Oct 22, 2014 at 3:42 PM, Philippe Riand wrote:
> Hello,
> If there any plan to get this in? (see:
> http://sqlite.org:8080/cgi-bin/mailman/private/sqlite-users/2014-September/055065.html
> )
You'll notice that the SQLite3 developers don't often discuss what
features they will be adding (n
Hello,
If there any plan to get this in? (see:
http://sqlite.org:8080/cgi-bin/mailman/private/sqlite-users/2014-September/055065.html
)
Note that this seems implemented by several databases now, and this is a
bit different from virtual columns, which is what the previous discussion
ended with. Virt
On Thu, Sep 4, 2014 at 3:59 AM, Dominique Devienne wrote:
> On Thu, Sep 4, 2014 at 2:04 AM, Nico Williams wrote:
>
>> [...] but there's a gotcha: SELECT * on a table
>> source with computed columns might result in much more work being done
>> than the user might have expected.
>
> If that's a rea
Dominique Devienne wrote:
(double-click on new version) SQLite version 3.8.5 2014-06-04 14:06:34
(terminal) SQLite version 3.7.13 2012-07-17 17:46:21
This means you downloaded the new version in a directory not in your $PATH
Add it to your path:
set PATH=: $PATH
If you do this in your start
On Thu, Sep 4, 2014 at 2:04 AM, Nico Williams wrote:
> [...] but there's a gotcha: SELECT * on a table
> source with computed columns might result in much more work being done
> than the user might have expected.
>
If that's a real concern, you can always use the existing HIDDEN keyword to
remov
Also, of course, MERGE is very convenient, syntactically and semantically.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
On Wed, Sep 3, 2014 at 6:16 PM, Simon Slavin wrote:
> I'm used to calling them 'computed columns' but yes, they should be
> relatively easy to implement, as long as users accept a bunch of restructions
> on what they can refer to, roughly equivalent to the restrictions on what can
> be used in
On 3 Sep 2014, at 8:21pm, John McKown wrote:
> Those are _both_ nice features. I don't know for sure, but somehow it
> seems that virtual columns would be easier to implement.
I'm used to calling them 'computed columns' but yes, they should be relatively
easy to implement, as long as users acc
On Wed, Sep 3, 2014 at 1:35 PM, Petite Abeille wrote:
>
> On Sep 3, 2014, at 3:01 PM, Dominique Devienne wrote:
>
>> Asked differently, if adding this support, could this be done by adding
>> virtual / computed columns to tables, and indexing those columns?
>
> Ohohohoho… virtual columns [1][2]….
On Sep 3, 2014, at 3:01 PM, Dominique Devienne wrote:
> Asked differently, if adding this support, could this be done by adding
> virtual / computed columns to tables, and indexing those columns?
Ohohohoho… virtual columns [1][2]…. yes… shinny! :)
Now that would be rather cool.
On the other
Use a trigger to populate your index column.
http://www.sqlite.org/lang_createtrigger.html
On Wed, Sep 3, 2014 at 9:01 AM, Dominique Devienne
wrote:
> On Wed, Sep 3, 2014 at 2:52 PM, Richard Hipp wrote:
>
> > SQLite does not (yet) support indexes on expressions.
>
>
> This begs the question: A
On Wed, Sep 3, 2014 at 2:52 PM, Richard Hipp wrote:
> SQLite does not (yet) support indexes on expressions.
This begs the question: Are there plans, possibly ongoing, to add this
support? Any timeframe?
Asked differently, if adding this support, could this be done by adding
virtual / computed
SQLite does not (yet) support indexes on expressions.
On Tue, Sep 2, 2014 at 9:06 PM, Philippe Riand wrote:
> Is there a way to create indexes based on expressions instead of simple
> columns (see:
> http://www.postgresql.org/docs/8.1/static/indexes-expressional.html)? The
> idea is to have som
Is there a way to create indexes based on expressions instead of simple
columns (see:
http://www.postgresql.org/docs/8.1/static/indexes-expressional.html)? The
idea is to have some custom functions that extract data from a JSON column
and allow a fast query based on an index. This is the strategy u
14 matches
Mail list logo
