Sandy Ganz wrote:
This doesn't sound right, I have seen the problem that linux will not use
the allocated memory until it is touched, but doesn't the memory manger keep
track ultimatly of all allocations (in the kernel which as all encompassing
knowledge of allocations) which might include things t
Original Message-
From: Henry Miller [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 04, 2005 12:37 PM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] Is there any way to enable recursive triggers?
On 1/4/2005 at 12:13 Sandy Ganz wrote:
>What OS does not return NULL or an exception wh
On 1/4/2005 at 12:13 Sandy Ganz wrote:
>What OS does not return NULL or an exception when malloc() fails or is
out
>of memory?
OS/2. Linux kernels < 2.6. I think Windows does this too, but I'm
not sure.
Its harder than you might think to implement, because most OSes don't
allocate memory
What OS does not return NULL or an exception when malloc() fails or is out
of memory?
Sandy
-Original Message-
From: Jay [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 04, 2005 12:06 PM
To: sqlite-users@sqlite.org; [EMAIL PROTECTED]
Subject: Re: [sqlite] Is there any way to enable
One poster mentioned some OS's will not let you know when you're
out of RAM (malloc() never fails). That might be difficult!
--- Darren Duncan <[EMAIL PROTECTED]> wrote:
> If possible, SQLite should also manage memory so that it has the
> resources necessary to roll back the infinite recursion
Regarding the risk of infinite loops with triggers ...
I believe that SQLite's default case should be to simply let
resources define the limits, and stop only when there simply aren't
the resources to continue.
As with most programming languages, it should be the user's
responsibility to not wr
mcea lt'il
m^Ne from two or more threads
**
-Original Message-
From: Jeremy Hinegardner [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 04, 2005 8:30 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Is there any way to enable recursive t
On Tue, Jan 04, 2005 at 05:54:04AM -0500, D. Richard Hipp wrote:
> One stubling block with recursive triggers is that a recursive
> trigger can result in an infinite loop. I sent out a query a
> month or so ago requesting ideas on how to detect and deal with
> infinite loops in recursive triggers.
On 1/4/2005 at 15:54 Paolo Vernazza wrote:
>>It seems to me that recursion that never touches the same row twice
is
>>less an issue. That is a trigger that just updates all other rows in
>>the table once should be fine. So one (I suspect hard to implement)
>>idea would be to keep track of which
On Jan 4, 2005, at 7:03 AM, Brass Tilde wrote:
FWIW, I'm told by our DBA that SQL Server 2000 has a setting that
allows or
disallows recursive trigger execution. When disallowed, triggers
apparently
just don't recursively call themselves, even if they are designed to
do so,
i.e. they won't g
> CREATE TRIGGER deep BEFORE DELETE ON list BEGIN
> DELETE FROM list WHERE id=old.next;
> END;
>
> This trigger is guaranteed to terminate because it will
> eventually run out of entries to delete. But given any
> recursion limit, we can always construct a case where
> the trigger
Henry Miller wrote:
It seems to me that recursion that never touches the same row twice is
less an issue. That is a trigger that just updates all other rows in
the table once should be fine. So one (I suspect hard to implement)
idea would be to keep track of which rows have been touched as part o
--- "D. Richard Hipp" <[EMAIL PROTECTED]> wrote:
> Peter Bartholdsson wrote:
> > Think the topic explains it but there any way to enable recursive
> triggers?
> > Aka, triggers that run as result of a change by a trigger.
> >
>
> Recursive triggers are on the todo list. They are a prerequisite
On 1/4/2005 at 08:48 D. Richard Hipp wrote:
>Peter Bartholdsson wrote:
>>
>> [H]ow would [limiting recursion depth] not be enough?
>>
>
>Limiting the recursion depth would be sufficient to prevent
>infinite loops. But it seems overly restrictive.
>
>Consider the following case:
>
>CREATE
> So do we put recursion limits on UPDATE and INSERT triggers
> only and let DELETE triggers run as long as they like?
> That works as far as I know, but it seems kind of arbitrary.
>
> Surely somebody else has been down this road before me and
> can offer a little guidance?
Why don't give this b
Peter Bartholdsson wrote:
[H]ow would [limiting recursion depth] not be enough?
Limiting the recursion depth would be sufficient to prevent
infinite loops. But it seems overly restrictive.
Consider the following case:
CREATE TABLE list(
id INTEGER PRIMARY KEY,
next INTEGER REFERENCES
On Tue, 04 Jan 2005 05:54:04 -0500, D. Richard Hipp <[EMAIL PROTECTED]> wrote:
Peter Bartholdsson wrote:
Think the topic explains it but there any way to enable recursive triggers?
Aka, triggers that run as result of a change by a trigger.
Recursive triggers are on the todo list. They are a prereq
I think that a good and simple solution is simply
limit the level of recursivity. Maybe 16 nested
recursive calls solve 95% of the recursive needs.
Cláudio
> Peter Bartholdsson wrote:
> > Think the topic explains it but there any way to
> enable recursive triggers?
> > Aka, triggers that run as
Peter Bartholdsson wrote:
Think the topic explains it but there any way to enable recursive triggers?
Aka, triggers that run as result of a change by a trigger.
Recursive triggers are on the todo list. They are a prerequisite
for the planned implementation of foreign keys.
One stubling block with
Think the topic explains it but there any way to enable recursive triggers?
Aka, triggers that run as result of a change by a trigger.
Regards,
Peter Bartholdsson
20 matches
Mail list logo