Running migrations not possible on custom schema

[melbic]

In our deployment environment we need to use the schema data instead of public. While the setting PGTRIGGER_SCHEMA works great when creating the triggers via management command, adding the triggers to migrations it breaks migrate.
Is that not possible or are we missing something?

[wesleykendall]

I dont see anything in the code that uses PGTRIGGER_SCHEMA in the management command, except for installing the global Postgres functions pgtrigger may use (not the triggers themselves)

The management command accepts a -s to set the search path. Is that what you're using?

The assumption that I made in pgtrigger is that the schema is a dynamic value, not something hardcoded in the trigger installation code. I.e. set your search path and the migrations will work. I did this for interoperability with multi-tenant setups. The PGTRIGGER_SCHEMA config is probably not the best name. This was created so that the global functions pgtrigger used could still have a static location even in a multi-tenant setup.

In your current setup, how are you creating tables in your migrations? Do those tables have a hardcoded schema? Is this even a supported feature in Django or does it come from a third party library?

I'd say the best workaround for now is to set the search path dynamically in migrations like -s does in the management command if you're blocked.

I could see PGTRIGGER_SCHEMA being used to set the default schema for everything, but it'd have to be a breaking change, and I do believe it would cause migration pain for some. I could see another pathway being PGTRIGGER_FUNC_SCHEMA and PGTRIGGER_TRIGGER_SCHEMA if the schema for triggers must be hardcoded. Or a schema property on the trigger (although this may not be the best for someone creating third-party libraries with triggers predefined)

Anyways, would be good to know how you current set schemas in your migrations