Amit Kapila <amit.kapila@huawei.com> writes:
> Below test results into Loop:
> [ AFTER INSERT trigger does another insert into its target table ]
Well, of course. The INSERT results in scheduling another AFTER event.
> I understand that user can change his code to make it proper.
> However shouldn$B!G(Bt PostgreSQL also throws errors in such cases for recursion
> level or something related?
No. In the first place, there is no recursion here: the triggers fire
sequentially, not in a nested way. In the second place, this sort of
thing is not necessarily wrong --- it's okay for a trigger to do
something like that, so long as it doesn't repeat it indefinitely.
(A human can see that this function will never stop adding rows, but
Postgres' trigger mechanism doesn't have that much insight.) In the
third place, we don't attempt to prevent queries from taking
unreasonable amounts of time, and a loop in a trigger is not very
different from anything else in that line. Use statement_timeout if
you're concerned about that type of mistake.
regards, tom lane