Addressing the particular points:
- If you create extensions in migrations – e.g. using
execute "create extension if not exists \"uuid-ossp\"", "";
– you don't need to do anything: they will be created in the heroku_ext
schema.
- Make sure all your
CREATE EXTENSION
calls use WITH SCHEMA heroku_ext
. E.g. CREATE EXTENSION IF NOT EXISTS unaccent WITH SCHEMA heroku_ext;
.
- To let PostgreSQL know that it should search also in the
heroku_ext
schema for extensions and therein present functions add after_connect: {Postgrex, :query!, _query_args = ["SET search_path TO public,heroku_ext", []]}
to your Repo config (more: [1], [2]) or adjust it to have heroku_ext
if you already had a custom search_path
. E.g.
config :app, App.Repo,
adapter: Ecto.Adapters.Postgres,
# ...
after_connect: {Postgrex, :query!, _query_args = ["SET search_path TO public,heroku_ext", []]}
Without the above you would need to call functions with a prefix/namespace qualifier e.g. heroku_ext.UNACCENT()
which would break an app if it would have extensions placed in different schemas.
After doing those the review app should be created successfully and also the production environment – in which extensions might be still placed in different schemas (e.g. public
or pg_catalog
) – will still work fine.
It's helpful to connect to the review apps' or staging/production apps' DBs and list the extensions they have e.g.:
% heroku pg:psql -a app-pr-123
app-pr-123::DATABASE=> \dx
List of installed extensions
Name | Version | Schema | Description
-----------+---------+------------+-------------------------------------------------
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
unaccent | 1.1 | heroku_ext | text search dictionary that removes accents
uuid-ossp | 1.1 | heroku_ext | generate universally unique identifiers (UUIDs)
(3 rows)
References