Thank you all for your comments.
> I would think that the queries in that case would be running as a
superuser in order to do the migrations.
Users of codd can choose the role that applies their migrations. Codd even supports individual migrations running with ad-hoc users (so that a migration can use the _postgres_ user to create the application's database, for example) and users are free to add statements like `SET ROLE` inside their migrations, too. So it's sadly not possible AFAICT to force superuser onto them.
But I think I have plenty of things to try to avoid this problem, from retrying like Tomas suggested to materialized CTEs that filter out temporary relations before functions like pg_get_indexdef are called.
I will give these things a shot.
Regards.
On 8/25/24 08:36, Marcelo Zabani wrote:
> > we do some special stuff for catalogs
>
> That is good to know, thanks!
>
> > I believe you could actually lock the pg_class rows for update. Just
> add FOR UPDATE at the end of the query.
>
> Thanks, but I tried that and got "ERROR: permission denied for table
> pg_class", even if I try it only for tables the user owns.
>
As I understand it this issue came up in:
https://github.com/mzabani/codd
I would think that the queries in that case would be running as a
superuser in order to do the migrations.
--
Adrian Klaver
adrian.klaver@aklaver.com
