:ruby schema dump not respecting search paths (postgres)

[HoneyryderChuck]

Whenever the schema is dumped, I have these lines in the end:

...
Sequel.migration do
     change do
         self << "SET search_path TO project_development"
....

I am using the same database for "development" and "test", and these define 2 different search paths. I set them in the database.yml (or DATABASE_URL, doesn't matter), that means, the db connection from Sequel knows beforehand in which search path to apply the migrations. Problem is, when this is part of the schema, I can't perform:

> RAILS_ENV=test bundle exec rake db:schema:load

Although the previous operations are going to be evaluated in the desired test search path, as soon as the migration line way above is executed, all subsequent operations will be evaluated in the development search path, thereby breaking everything. As you might know, everything coming after are schema_migration entries for every migration ran, and this already exists in the development search path, as the schema was dumped from there(!).

So, I think setting the search path should be out of the schema dump.

[HoneyryderChuck]

Would also like to add, it seems also "buggy" in the sql structure dump. See https://github.com/TalentBox/sequel-rails/blob/ad1a51b3ee45f90c99e28413bcc9d45c1eaf2eb8/lib/sequel_rails/storage/abstract.rb#L117-L122 . I don't know exactly where it happens, but the dump contains:

CREATE SCHEMA proj_dev;

CREATE EXTENSION IF NOT EXISTS plpgsql WITH SCHEMA pg_catalog;

COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language';

SET search_path = proj_dev, pg_catalog;

I don't know if this comes from sequel or is injected by sequel-rails, but I'd say that, the same way that the dump doesn't try to create the database and the db user/role, it also shouldn't try to create the schemas, which is all part of expected information to connect.

[HoneyryderChuck]

I've just confirmed, structure:dump issue is from sequel-rails. I think it uses the psql cli tool to generate it, and search_path info comes with it. No easy way to circumvent this with this strategy, I guess.