PostgreSQL の `rails dbconsole` が `schema_search_path` を尊重するように変更

rails dbconsole が config/database.yml の schema_search_path 設定を無視し、デフォルトの検索パスで起動していた問題を解消しました。PGOPTIONS に search_path を自動的に付与し、アプリケーションとコンソールの接続設定を一致させます。

背景

これまで rails dbconsole は PostgreSQL 用に PGOPTIONS を組み立てる際、schema_search_path を考慮しませんでした。その結果、アプリケーションはカスタムスキーマで動作していても、コンソールは $user,public で接続され、手動で SET search_path を実行する必要がありました。開発者は同一データベース構成を前提にコマンドライン操作を行うことができず、作業効率が低下していました。PR の目的は、rails dbconsole が設定ファイルの schema_search_path をそのまま反映し、psql セッションとアプリケーションの接続設定を同一にすることです。

技術的な変更

PostgreSQLAdapter#dbconsole の実装が拡張され、config.configuration_hash を deep_dup してから環境変数を設定するようになりました。これにより元のハッシュが不要に変更されることを防ぎます。

pg_config = config.configuration_hash.deep_dup

続いて、schema_search_path が存在すれば variables[:search_path] に代入するロジックが追加されました。既存の variables がある場合はそのハッシュを再利用し、search_path が既に指定されている場合は上書きしません。

if pg_config[:schema_search_path]
  pg_config[:variables] ||= {}
  pg_config[:variables][:search_path] ||= pg_config[:schema_search_path]
end

variables が設定されているときは、各キー‐バリューを -c name=value 形式に変換して PGOPTIONS に格納します。この変換ロジックは変更前後で同一で、search_path が追加された場合でも既存のオプションと正しく結合されます。

テストコードも新規追加され、schema_search_path 単体、variables と併用、そして variables が search_path を上書きしないケースを検証しています。テストは PostgreSQLAdapter.dbconsole が期待通り PGOPTIONS を設定することを確認し、回帰防止を担保します。

assert_equal "-c search_path=my_schema,\\ default,\\ \\my_schema", ENV["PGOPTIONS"]

最後に CHANGELOG に新機能としてエントリが追加され、変更点が公開されています。

+*   Respect `schema_search_path` on `rails dbconsole` for PostgreSQL.
+    *Gabriel Sobrinho*

設計判断

この変更は 設定ハッシュの不変性 を保ちつつ機能追加するという方針で実装されました。deep_dup により元の config が汚染されないため、他のコンポーネントが同一ハッシュを参照していても副作用が発生しません。さらに、variables[:search_path] のデフォルト設定は ||= 演算子で行われ、利用者が明示的に search_path を上書きした場合は優先されます。これにより既存の variables 拡張機構との互換性が維持され、後方互換性が担保されています。

また、コードの最小侵入 を重視し、既存ロジックを改変せずに新しい処理を前段に追加しました。結果として dbconsole の挙動は従来通り動作しつつ、schema_search_path が自動的に反映されるだけのシンプルな拡張となっています。

まとめ

rails dbconsole が schema_search_path を尊重するようになったことで、アプリケーションとコンソールの接続設定が一致し、手動設定の手間が省かれます。実装は設定ハッシュの安全なコピーと variables へのデフォルト注入という形で行われ、既存機能との互換性を損なわない設計判断が取られました。この変更は PostgreSQL 環境での開発効率向上に直結します。