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.
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 Sun, Aug 25, 2024 at 1:13 PM Adrian Klaver <adrian.klaver@xxxxxxxxxxx> wrote:
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@xxxxxxxxxxx
