Aleksander Alekseev writes:
>> Perhaps we should leave the system triggers out of the discussion
>> entirely? More or less like:
>>
>> If a foreign key constraint specifies referential actions (that
>> is, cascading updates or deletes), those actions are performed via
>> ordinary SQL update or d
Hi,
> Perhaps we should leave the system triggers out of the discussion
> entirely? More or less like:
>
> If a foreign key constraint specifies referential actions (that
> is, cascading updates or deletes), those actions are performed via
> ordinary SQL update or delete commands on t
Aleksander Alekseev writes:
>> I agree with documenting this hazard, but I think it'd be better
>> to do so in the "Triggers" chapter. There is no hazard unless
>> you are writing user-defined triggers, which is surely far fewer
>> people than use foreign keys. So I suggest something like the
>>
Hi,
> Laurenz Albe writes:
> > Patch v3 is attached.
>
> I agree with documenting this hazard, but I think it'd be better
> to do so in the "Triggers" chapter. There is no hazard unless
> you are writing user-defined triggers, which is surely far fewer
> people than use foreign keys. So I sugge
Laurenz Albe writes:
> Patch v3 is attached.
I agree with documenting this hazard, but I think it'd be better
to do so in the "Triggers" chapter. There is no hazard unless
you are writing user-defined triggers, which is surely far fewer
people than use foreign keys. So I suggest something like
On 22.12.2023 14:39, Laurenz Albe wrote:
Yes, that is better - shorter and avoids passive mode. Changed.
Thanks.
Also I don't really like "This is not considered a bug" part, since it
looks like an excuse.
In a way, it is an excuse, so why not be honest about it.
I still think that the "t
On Fri, 2023-12-22 at 10:59 +0300, Pavel Luzanov wrote:
> Please, consider small suggestion to replace last sentence.
>
> - This is not considered a bug, and it is the responsibility of the user
> to write triggers so that such problems are avoided.
> + It is the trigger programmer's responsibili
One more not documented issue with system triggers. It might be worth
considering together.
CREATE ROLE app_owner;
CREATE TABLE t (
id int PRIMARY KEY,
parent_id int REFERENCES t(id)
);
ALTER TABLE t OWNER TO app_owner;
-- No actions by application owner
REVOKE ALL ON t FROM ap
I fully support this addition to the documentation. The legal
possibility of breaking data consistency must be documented at least.
Please, consider small suggestion to replace last sentence.
- This is not considered a bug, and it is the responsibility of the user
to write triggers so that suc
Hi,
> Attached is a slightly modified version of the patch.
The patch was marked as "Needs Review" so I decided to take a look.
I believe it's a good patch. The text is well written, has the
necessary references, it warns the user but doesn't scare him/her too
much.
> I couldn't make it clearer
Thanks for having a look at my patch!
On Mon, 2023-10-30 at 15:03 -0700, David G. Johnston wrote:
> On Mon, Oct 30, 2023 at 2:50 PM David G. Johnston
> wrote:
> > On Tue, Oct 3, 2023 at 12:52 AM Laurenz Albe
> > wrote:
> > > On Mon, 2023-10-02 at 09:49 -0400, Tom Lane wrote:
> > > > This is by
On Mon, Oct 30, 2023 at 2:50 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Tue, Oct 3, 2023 at 12:52 AM Laurenz Albe
> wrote:
>
>> On Mon, 2023-10-02 at 09:49 -0400, Tom Lane wrote:
>> > This is by design: triggers operate at a lower level than
>> > foreign keys, so an ill-concei
On Tue, Oct 3, 2023 at 12:52 AM Laurenz Albe
wrote:
> On Mon, 2023-10-02 at 09:49 -0400, Tom Lane wrote:
> > This is by design: triggers operate at a lower level than
> > foreign keys, so an ill-conceived trigger can break an FK constraint.
> > That's documented somewhere, though maybe not visibl
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:tested, passed
It seems like people have been talking about this problem since 2010
(ht
On Mon, Oct 02, 2023 at 09:49:53AM -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > CREATE FUNCTION silly() RETURNS trigger LANGUAGE plpgsql AS 'BEGIN RETURN
> > NULL; END;';
> > CREATE TRIGGER silly BEFORE DELETE ON child FOR EACH ROW EXECUTE FUNCTION
> > silly();
>
> > The trigger function c
On Mon, 2023-10-02 at 09:49 -0400, Tom Lane wrote:
> This is by design: triggers operate at a lower level than
> foreign keys, so an ill-conceived trigger can break an FK constraint.
> That's documented somewhere, though maybe not visibly enough.
Not having found any documentation, I propose the a
On Mon, 2023-10-02 at 09:49 -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > CREATE FUNCTION silly() RETURNS trigger LANGUAGE plpgsql AS 'BEGIN RETURN
> > NULL; END;';
> > CREATE TRIGGER silly BEFORE DELETE ON child FOR EACH ROW EXECUTE FUNCTION
> > silly();
>
> > The trigger function cancels
Laurenz Albe writes:
> CREATE FUNCTION silly() RETURNS trigger LANGUAGE plpgsql AS 'BEGIN RETURN
> NULL; END;';
> CREATE TRIGGER silly BEFORE DELETE ON child FOR EACH ROW EXECUTE FUNCTION
> silly();
> The trigger function cancels the cascaded delete on "child", and we are left
> with
> a row i
Perhaps it would be enough to run "RI_FKey_noaction_del" after
"RI_FKey_cascade_del", although that would impact the performance.
Yours,
Laurenz Albe
CREATE TABLE parent (id integer PRIMARY KEY);
CREATE TABLE child (id integer REFERENCES parent ON DELETE CASCADE);
CREATE FUNCTION silly() RETURNS trigger LANGUAGE plpgsql AS 'BEGIN RETURN NULL;
END;';
CREATE TRIGGER silly BEFORE DELETE ON child FOR EACH ROW EXECUTE FUNCTION
silly();
INSERT I
20 matches
Mail list logo
