> To be honest..No trigger necessary...
I have 1300 triggers and 345 functions (53500 lines of code), most of
them written 15 years ago for ALLBASE/SQL (the old Hewlett Packard
relational dbms) and converted to pl/pgsql last year.
I admit that some of them may look eccentric, but some of them a
On Wed, Jun 27, 2007 at 11:37:01AM +0200, Manera, Villiam wrote:
> To better explain my problem I attach one of my functions that is easy
> to understand.
>
> For each of my products I must have one main supplier and I may have
> also some secondary suppliers.
>
> Therefore for each of my articl
Tom Lane wrote:
We could possibly re-allow that (see the comments in AlterTable()) but
it seems like an ugly and inefficient technique that we shouldn't be
encouraging. (The implications for system catalog bloat alone seem
enough reason to not recommend this.) Isn't there a cleaner way to
design
Chris Mair <[EMAIL PROTECTED]> writes:
> On the italian list we're discussing a case were a user reportedly
> worked around this (i.e. got rid of unwanted cascading calls) by
> writing an on insert trigger procedure something on the lines of:
> ALTER TABLE tab DISABLE TRIGGER USER;
> -- do more
On Jun 26, 2007, at 10:04 , Chris Mair wrote:
Hello,
On the italian list we're discussing a case were a user reportedly
worked around this (i.e. got rid of unwanted cascading calls) by
writing an on insert trigger procedure something on the lines of:
ALTER TABLE tab DISABLE TRIGGER USER;
--
Hello,
triggers in PostgreSQL are cascading by default. From section 34.1.
of the 8.2 manual:
"If a trigger function executes SQL commands then these commands
may fire triggers again. This is known as cascading triggers.
There is no direct limitation on the number of cascade levels.
I
