On 07/14/18 20:09, E.Pasma wrote:
The new example is clear, and therefore also raises a question:
CREATE TABLE people (name, age);
INSERT INTO people VALUES ('Bob', 33), ('Jen', 19), ('Liz', 30);
CREATE VIEW older PARAMETERS (name, otherName) AS
SELECT t1.age > t2.age AS older
FROM people
Hello,
The new example is clear, and therefore also raises a question:
> CREATE TABLE people (name, age);
> INSERT INTO people VALUES ('Bob', 33), ('Jen', 19), ('Liz', 30);
>
> CREATE VIEW older PARAMETERS (name, otherName) AS
> SELECT t1.age > t2.age AS older
> FROM people AS t1 WHERE t1.name
On 07/07/18 19:47, E.Pasma wrote:
But the ideas allow a parameter name to be identical to a column name,
which must be an error.
While I might prefer that to be the case, it's actually not. We do not
have the ability for column expressions to reference other columns, so
there is no
> 4 jul. 2018, Andy Goth:
> Revisiting this topic...
>
> On 06/10/18 08:04, sql...@zzo38computer.org wrote:
>> * Perhaps move PARAMETERS before AS, which may make the syntax easier.
>
> Like so?
>
> CREATE VIEW double PARAMETERS (arg) AS SELECT arg * 2;
> SELECT * FROM numbers, double(x);
>
>
Revisiting this topic...
On 06/10/18 08:04, sql...@zzo38computer.org wrote:
* Perhaps move PARAMETERS before AS, which may make the syntax easier.
Like so?
CREATE VIEW double PARAMETERS (arg) AS SELECT arg * 2;
SELECT * FROM numbers, double(x);
This is a readability improvement because
I have some of my own ideas about this.
* Perhaps move PARAMETERS before AS, which may make the syntax easier.
* You don't need computed columns in tables; use views instead. You can index
computed values though.
* I do agree that defining table-valued functions in these way can be useful
On Sun, Jun 10, 2018 at 7:48 AM Simon Slavin wrote:
> On 10 Jun 2018, at 2:40pm, J Decker wrote:
>
> > forget contributing code ... but funding? how much can I pay to get
> better
> > NUL support?
>
> Can you tell us what's wrong with NUL support ?
>
I have, repeatedly.
> The best changes
On 10 Jun 2018, at 2:40pm, J Decker wrote:
> forget contributing code ... but funding? how much can I pay to get better
> NUL support?
Can you tell us what's wrong with NUL support ?
The best changes come free. Because they're bug-fixes, or obvious improvements
worth the increase in code
On Sat, Jun 9, 2018 at 7:37 PM Andy Goth wrote:
>
> This is probably not going to be added
> until SQLite's primary developers themselves decide they need it, or
> until someone else decides it's important enough to them to contribute
> code and/or funding.
>
forget contributing code ... but
> What problem are you having with trigger performance?
My primary use of triggers in SQLite is on insert/update and using RAISE.
Not sure where the trigger overhead comes from, but
If I place a simple check in CHECK and have a trigger with the same CHECK then
CHECK is way faster than a trigger.
>boun...@mailinglists.sqlite.org] On Behalf Of Keith Medcalf
>Sent: Saturday, 9 June, 2018 22:06
>To: SQLite mailing list
>Subject: Re: [sqlite] Idea: defining table-valued functions directly
>in SQL
>
>
>Do you have an appropriate index defined on both the parent and chil
t;From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of David Burgess
>Sent: Saturday, 9 June, 2018 21:44
>To: SQLite mailing list
>Subject: Re: [sqlite] Idea: defining table-valued functions directly
>in SQL
>
>> reminder that views can hav
> reminder that views can have triggers
Anyone else have an issue with trigger performance in SQLite?
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
On 6/9/2018 8:31 PM, Simon Slavin wrote:
> On 10 Jun 2018, at 2:18am, Andy Goth wrote:
>> Skip computed columns in the value list? If two tables have the same
>> schema, this should duplicate one into the other, but apparently not:
>>
>> INSERT INTO table2 SELECT * from table1;
>
> This syntax,
.
>-Original Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of Andy Goth
>Sent: Saturday, 9 June, 2018 19:18
>To: sqlite-users@mailinglists.sqlite.org
>Subject: Re: [sqlite] Idea: defining table-valued functions directly
>
On 10 Jun 2018, at 2:18am, Andy Goth wrote:
> However, views make behavior of INSERT and UPDATE clear, since they can
> only operate on the real table. INSERT or UPDATE become murky when in
> the presence of computed columns. I suppose the only sane thing to do
> is forbid directly setting the
On 06/09/18 20:10, Simon Slavin wrote:
On 10 Jun 2018, at 2:00am, Andy Goth wrote:
CREATE TABLE tempLog (
datestamp TEXT COLLATE NOCASE PRIMARY KEY
, centTemp REAL);
CREATE VIEW tempLogView AS
SELECT *
, centTemp * 9 / 5 + 32 AS fahrTemp
FROM tempLog;
Yes. That is
On 10 Jun 2018, at 2:00am, Andy Goth wrote:
> CREATE TABLE tempLog (
> datestamp TEXT COLLATE NOCASE PRIMARY KEY
> , centTemp REAL);
> CREATE VIEW tempLogView AS
> SELECT *
> , centTemp * 9 / 5 + 32 AS fahrTemp
> FROM tempLog;
Yes. That is an elegant and compact way to do
On Sat, Jun 9, 2018 at 7:00 PM, Andy Goth wrote:
> On 06/09/18 18:04, Simon Slavin wrote:
>>
>> CREATE TABLE tempLog (
>> datestamp TEXT COLLATE NOCASE PRIMARY KEY,
>> centTemp REAL,
>> fahrTemp AS (centTemp*9/5 + 32) )
>>
>> I'm happy with another syntax as long as it does the same
On 06/09/18 18:04, Simon Slavin wrote:
CREATE TABLE tempLog (
datestamp TEXT COLLATE NOCASE PRIMARY KEY,
centTemp REAL,
fahrTemp AS (centTemp*9/5 + 32) )
I'm happy with another syntax as long as it does the same thing.
CREATE TABLE tempLog (
datestamp TEXT COLLATE NOCASE
On 06/09/18 19:46, David Burgess wrote:
There are some functions which are banned.
Are extension functions permitted?
https://sqlite.org/c3ref/create_function.html
And how does an extension function author indicate that the function
is deterministic?
Notice that the view isn't bound to the numbers table or its x column
until it's actually used in the SELECT query. [...] This might also
make it possible for a table-valued function to recursively invoke
itself, provided that it has a basis case to avoid infinite descent.
We already have
> There are some functions which are banned.
Are extension functions permitted?
And how does an extension function author indicate that the function
is deterministic?
On Sun, Jun 10, 2018 at 10:23 AM, Simon Slavin wrote:
> On 10 Jun 2018, at 1:09am, David Burgess wrote:
>
>> full_account_number
On 10 Jun 2018, at 1:09am, David Burgess wrote:
> full_account_number AS ( branch || account_number )
>
> or
>
> branch AS (substr(full_account_number,1,4)),
> account_number AS (substr(full_account_number,5))
All the above are allowed in computed columns. There are some functions which
are
Would schema defined functions fulfill the same requirement (e.g.
return val = p1 || p2) ?
Computed columns would be of assistance to me, assuming that functions
are permitted. e.g.
full_account_number CHAR(16),
branch CHAR(4),
account_number CHAR(12),
full_account_number AS ( branch ||
On 9 Jun 2018, at 9:21pm, Andy Goth wrote:
> I suggest extending SQLite views and common table expressions to be the
> vehicle for defining table-valued functions directly in SQL.
I'll raise your bid. I want computed columns (SQL SERVER), otherwise known as
generated columns (MySQL).
Table-valued functions can only be defined within compiled application
code by means of virtual tables. I suggest extending SQLite views and
common table expressions to be the vehicle for defining table-valued
functions directly in SQL.
A view or common table expression that references
27 matches
Mail list logo
