From: "Simon Slavin"
Sent: Monday, April 26, 2010 2:31 PM
> I don't know the answer to this question, but I have considered it in one
> of my
> programs. It simply issues a "PRAGMA recursive_triggers = 'on'", then
> does a
> "PRAGMA recursive_triggers" and looks to see what it gets back. Anythi
On 26 Apr 2010, at 11:09am, Andy Gibbs wrote:
> I notice in the fossil repository that Sqlite is now moving towards version
> 3.7.0. According to the pagehttp://www.sqlite.org/news.html#2009_sep_11, it
> is anticipated that recursive triggers will be enabled by default from
> version 3.7.0 (c
Hi,
I notice in the fossil repository that Sqlite is now moving towards version
3.7.0. According to the page http://www.sqlite.org/news.html#2009_sep_11, it
is anticipated that recursive triggers will be enabled by default from version
3.7.0 (cf also http://www.sqlite.org/limits.html#max_trigg
> The same is true of FOREIGN KEY, by the way (I checked), but that's a bit
> more obvious since breaking FOREIGN KEY will always result in a database the
> programmer would consider corrupt.
You're not quite right. You're talking about immediate foreign keys.
There're deferred foreign keys too.
On 25 Nov 2009, at 2:06pm, Pavel Ivanov wrote:
>> I couldn't find the answer documented anywhere, so I will have to assume
>> that it may change in future versions. Unless the requirement for depth
>> first is somewhere in the SQL specification.
>
> I believe it should be. Triggers should be
> I couldn't find the answer documented anywhere, so I will have to assume that
> it may change in future versions. Unless the requirement for depth first is
> somewhere in the SQL specification.
I believe it should be. Triggers should be executed before the
statement causing them to fire is co
On 25 Nov 2009, at 1:38pm, Pavel Ivanov wrote:
> Does this answers question?
I think it does for the current version: depth first. Thanks.
I couldn't find the answer documented anywhere, so I will have to assume that
it may change in future versions. Unless the requirement for depth first is
Does this answers question?
sqlite> create table log (t);
sqlite> create table t1 (a);
sqlite> create table t2 (a);
sqlite> create trigger tt1 after update on t1 begin
...> insert into t2 values (new.a);
...> insert into log values ("update of t1, a="||new.a);
...> end;
sqlite> create tri
This new implementation of recursive TRIGGERs. Is it depth-first or
width-first ?
Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Hello everyone!
It's been almost two years since the last round of discussions about
recursive trigger implementation (on this mailing list). Are there any news
about their support in near future? (same with foreign keys)
I wish there was a rough schedule for the unsupported features (
http://www
Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 26. April 2007 21:05
An: sqlite-users@sqlite.org
Betreff: Re: [sqlite] Recursive triggers
"Michael Ruck" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I've been looking into the way trig
"Michael Ruck" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I've been looking into the way triggers are implemented and was thinking
> about adding support for recursive triggers, as they would simplify my
> current project dramatically. What was/is the reason to leave them out?
>
> My thoughts were a
Hello,
I've been looking into the way triggers are implemented and was thinking
about adding support for recursive triggers, as they would simplify my
current project dramatically. What was/is the reason to leave them out?
My thoughts were adding recursive triggers by calling them like subroutine
Hi all,
I want to create recursive trigger in my application does SQLite supports
this?
Actually I have one table where parent child relationship exists between the
columns. So if parent row
gets deleted the children should also get deleted.
So how could I get this from SQLite.
I have
I recently step over a problem where recursive triggers are really
helpfull, and realized that my idea for propagating changes along a tree
structure won't work without recursive triggers obviously.
In short, I think the server sql engines implement recursion limits because
they are mulit-user. So
On Fri, 03 Dec 2004 19:04:56 -0500, D. Richard Hipp <[EMAIL PROTECTED]> wrote:
SQLite does not currently support recursive triggers.
On of the main reasons for not supporting recursive
triggers is that disallowing recursive triggers was
seen as the easiest way to avoid infinite loops like
this:
On Fri, Dec 03, 2004 at 07:04:56PM -0500, D. Richard Hipp wrote:
> By disallowing recursive triggers, SQLite avoids the
> infinite loop above. But there are useful things one
> could do with recursive triggers that do not involve
> infinite loops. I would like to relax the constraint
> Question
On Dec 3, 2004, at 4:04 PM, D. Richard Hipp wrote:
SQLite does not currently support recursive triggers.
On of the main reasons for not supporting recursive
triggers is that disallowing recursive triggers was
seen as the easiest way to avoid infinite loops like
this:
CREATE TRIGGER loop AFTER UP
SQLite does not currently support recursive triggers.
On of the main reasons for not supporting recursive
triggers is that disallowing recursive triggers was
seen as the easiest way to avoid infinite loops like
this:
CREATE TRIGGER loop AFTER UPDATE OF table1
BEGIN
UPDATE table1 SET cnt=
19 matches
Mail list logo