Hi @José Pereira , you can use the maxerrors flags in a USING clause to bail out earlier, though I'm guessing you're actually already using it to achieve the opposite and make sure you process all the correct rows.
We're intentionally writing verbose logs as that was an explicit request early on. As for retention, that was overlooked in the initial release, but is a roadmap item to make this follow the existing PurgeErrors CPF setting (and I'll add a note to the ticket you brought it up). In the absence of that, you can just use DELETE or TRUNCATE on these log tables.
I think @Alexander Koblov actually meant "Yes" :-), as row-level security was indeed designed for exactly this purpose, to inject additional filters into queries based on their credentials.
that first line is required to initialize the mbChunk variable used in the loop, else you'd get an UNDEFINED at runtime.
I'm thinking the way how you're using this macro is slightly off, and this has the same root cause as the other thread you opened. This macro is expected to be used on its own:
hope this helps