On Tuesday 01 of April 2014 11:06:00 you wrote:
> On Tue, Apr 1, 2014 at 9:13 AM, Andrzej Mazurkiewicz <
>
> andr...@mazurkiewicz.org> wrote:
> > It seems that if the trigger is internal (tgisinternal = true) it is not
> > visible to the DROP TRIGGER command. So it cannot be deleted using DROP
> >
On Tue, Apr 1, 2014 at 8:13 AM, Andrzej Mazurkiewicz
wrote:
> That change is necessary to reduce scope of modifications necessary for an
> implementation of the inheritance of foregn key constraints, particularly for
> removing of objects.
Nobody here is going to accept that goal as a valid reaso
Andrzej Mazurkiewicz writes:
> After reading please comment if there are more objections for changing the
> depedency type for trigger to constraint dependency from the
> DEPENDENCY_INTERNAL to DEPENDENCY_AUTO.
I'm not sure which part of "no" you didn't understand, but we're not
doing that.
>
On Tue, Apr 1, 2014 at 9:13 AM, Andrzej Mazurkiewicz <
andr...@mazurkiewicz.org> wrote:
>
> It seems that if the trigger is internal (tgisinternal = true) it is not
> visible to the DROP TRIGGER command. So it cannot be deleted using DROP
> TRIGGER command, although the dependency type is DEPENDENC
Good Afternoon.
Enclosed please find continuation of the discussion of an accidental or
malicious breaking a server consistency.
After reading please comment if there are more objections for changing the
depedency type for trigger to constraint dependency from the
DEPENDENCY_INTERNAL to DEPEND
Andrzej Mazurkiewicz writes:
>> So in other words, somebody could (accidentally or maliciously) break the
>> constraint by dropping one of its implementation triggers. I doubt that's
>> acceptable.
> The present postgres behavior ALLOWS accidental or malicious break the
> constraint by dropping
Good Morning.
1. At the beginning some explanations.
I am a lazy person that tries not to reinvent a wheel.
So I try to use postgres way of automatic processing, i. e. automatic removing
dependent objects (which I consider an elegant solution and I really like it).
A a result, I have used the p
Andrzej Mazurkiewicz writes:
> My patch need one change that might be of significance.
> A type of the depencencies (pg_depend) among the FK constraint
> (pg_constraint)
> and the corresponding "RI_ConstraintTrigger" triggers has to be changed from
> DEPENDENCY_INTERNAL to DEPENDENCY_AUTO.
So
http://wiki.postgresql.org/wiki/Todo
Section "Inheritance"
"Allow inherited tables to inherit indexes, UNIQUE constraints, and
primary/FOREIGN KEYS"
Good Morning.
I started to program a patch for inheritance of the foreign key constraints.
I. e. after applying the patch FKs are maintained bet