On Thursday, 28 March, 2019 13:21, Mark Wagner wrote:
>Imagine I have these two tables and one view defining a join.
>CREATE TABLE t (foo);
>CREATE TABLE s (bar);
>CREATE VIEW v as select * from t join s on (foo = q);
>I appear to be able to do this query:
>select 20 as q, * from t join s on
On 3/28/2019 3:21 PM, Mark Wagner wrote:
Imagine I have these two tables and one view defining a join.
CREATE TABLE t (foo);
CREATE TABLE s (bar);
CREATE VIEW v as select * from t join s on (foo = q);
Surprisingly, this last statement succeeds. But if you then close the database and try to
From the page https://sqlite.org/lang_createview.html :
"The CREATE VIEW command assigns a name to a pre-packaged SELECT
statement ..."
So, it seems that the command "CREATE VIEW" just creates a name for a
SELECT statement, and checks nothing more than syntax.
On 28.3.2019 21:21, Mark
Imagine I have these two tables and one view defining a join.
CREATE TABLE t (foo);
CREATE TABLE s (bar);
CREATE VIEW v as select * from t join s on (foo = q);
I appear to be able to do this query:
select 20 as q, * from t join s on (foo=q);
But apparently I cannot do this:
sqlite> select 20
Hmmm right, valid points.
The queries I'm doing are on slices of data that are preselected using
indices, and then right now I'm post-filtering them in the application, and
I was just wondering if I could already do better filtering on the db side
before paying the serialization costs.
In fact,
On Mar 28, 2019, at 4:15 AM, Wout Mertens wrote:
>
> - I don't see how json_type can help
I don’t see “json_type” in this thread at all, other than this message.
> - Schemaless data is really nice to work with
Sure, but it has a cost. Unless you’re willing to give us a *lot* more
Hi,
A very simple reproducer bash script using the sqlite3 CLI is appended
at the end.
I am using WAL mode in a setting with sequential writes and many
concurrent reads. Due to WAL mode the readers don't get blocked, which
is great and since writes are sequential, they never get blocked
On 28 Mar 2019, at 10:25am, Dominique Devienne wrote:
> Some info about the statement from EXPLAIN QUERY PLAN, that DRH would agree
> to, and accept to "publicly document" and thus support would be nice,
You want something like
EXPLAIN EFFECTS OF
and it should answer with zero or more
Oooo this is really neat. Thanks!
> On Mar 27, 2019, at 5:12 PM, Richard Hipp wrote:
>
> See https://www.sqlite.org/carray.html
>
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
>
On Thu, Mar 28, 2019 at 1:16 PM Clemens Ladisch wrote:
> Jeffrey Walton wrote:
> > When working in the Linux terminal we can clear the scrollback with
> > the 'clear' command; and we can delete all history and scrollback with
> > the 'reset' command. I am not able to do the same within the
On Thu, Mar 28, 2019 at 1:35 PM Hick Gunter wrote:
> IMHO the sqlite3_set_authorizer() interface already does a pretty decent
> job of providing the requested information:
>
True, but only if you are fully in control, because authorizer do not
"stack". There's only one, you can't get to restore
IMHO the sqlite3_set_authorizer() interface already does a pretty decent job of
providing the requested information:
asql> explain insert into tx7300.vals(keyid,value,sync_offset)
...> select k.id,tx.retailer_loc_id,tx.sync_offset from tx7300.keys k,
atx_txlog tx where k.name='retailer_loc_id'
Jeffrey Walton wrote:
> When working in the Linux terminal we can clear the scrollback with
> the 'clear' command; and we can delete all history and scrollback with
> the 'reset' command. I am not able to do the same within the sqlite3
> terminal.
Those are programs run from the shell. So you
Hi,
When working in the Linux terminal we can clear the scrollback with
the 'clear' command; and we can delete all history and scrollback with
the 'reset' command. I am not able to do the same within the sqlite3
terminal.
I'd like to request a '.clear' command and a '.reset' command to do
the
I think it can all be done in a single table, with columns, A, B, C,
type, Name, and other things, with indexes/constraints
UNIQUE(A, B, C, Type)
UNIQUE(Name, Type)
and quite possible an addition PRIMARY index, perhaps the default ROWID
one, as neither of those UNIQUE indexes look to be ideal as
On Thu, Mar 28, 2019 at 10:59 AM R Smith wrote:
> Maybe even, if possible, This query updates these tables: x1, x2, x3...
> etc. (some of which might hide behind an FK relation or Trigger) but I
> know this is pushing my luck. :)
>
What I ended-up doing is introspecting the VDBE program of
To answer all emails in this thread:
- I don't see how json_type can help, I want to query the keys of objects
- Schemaless data is really nice to work with, the wrapper I use does
allow putting parts of the JSON object into real columns but changing the
production db schema all the
On 2019/03/28 9:07 AM, Olivier Mascia wrote:
Le 27 mars 2019 à 18:04, siscia a écrit :
I would like to propose a function (named `sqlite3_stmt_action` for the sake
of discussion) that allow to understand if a specific statement is either a
SELECT, UPDATE, DELETE or INSERT.
There is probably a
You can use a simple 'L' flag on the rows you want locked and add a
where to don't touch them.
I'm afraid things are more complicated in many real-world cases.
Locking a single row isn't enough.
What if the UPDATE or DELETE forces deep changes in one or more indices?
What if the UPDATE or
On Thu 28 Mar 2019 at 08:07, Olivier Mascia wrote:
>
> > Le 27 mars 2019 à 18:04, siscia a écrit :
> >
> > I would like to propose a function (named `sqlite3_stmt_action` for the
> sake
> > of discussion) that allow to understand if a specific statement is
> either a
> > SELECT, UPDATE, DELETE
> Le 27 mars 2019 à 18:04, siscia a écrit :
>
> I would like to propose a function (named `sqlite3_stmt_action` for the sake
> of discussion) that allow to understand if a specific statement is either a
> SELECT, UPDATE, DELETE or INSERT.
There is probably a much more complex need that I did
21 matches
Mail list logo
