Re: BEFORE triggers that return NULL can circumvent referential integrity
От | Pavel Stehule |
---|---|
Тема | Re: BEFORE triggers that return NULL can circumvent referential integrity |
Дата | |
Msg-id | CAFj8pRC9oVLgtjOLPCxcsH0kpb8xKMdhC9pG3ZqQMXwZq4o-=w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BEFORE triggers that return NULL can circumvent referentialintegrity (Jim Finnerty <jfinnert@amazon.com>) |
Ответы |
Re: BEFORE triggers that return NULL can circumvent referentialintegrity
|
Список | pgsql-bugs |
út 30. 10. 2018 v 22:05 odesílatel Jim Finnerty <jfinnert@amazon.com> napsal:
re: There is also nonstandard behavior if BEFORE triggers modify rows or
prevent updates during an update that is caused by a referential
action. This can lead to constraint violations or stored data that
does not honor the referential constraint.
That supports the position that it was already documented, I'll grant you
that. It is clearly a bug if it causes foreign key constraints to be
violated, documented or not. Otherwise foreign key constraints mean nothing
in PostgreSQL.
I don't think this would be particularly difficult to fix so that it causes
the statement to fail when there is a referential action, rather than
silently returning and leaving the database in an inconsistent state.
What is the argument in favor of retaining behavior that renders foreign
keys meaningless?
What is the process for deciding whether a report represents an actionable
bug that ought to be fixed by the community?
You should to send mail to pgsql-hackers mailing list and send proposal to change the behave.
When there are complex bugs, then you should to design a solution. The bug report is nothing when there is not a possible solution.
The design of BEFORE trigger (NULL returning) is often used pattern and there are not any chance so Postgres drops this feature.
Lot of similar issues are solved by documentation bugfix. The risk is better described.
Regards
Pavel
/Jim
-----
Jim Finnerty, AWS, Amazon Aurora PostgreSQL
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-bugs-f2117394.html
В списке pgsql-bugs по дате отправления: