[5.3] Fix support for multi-schema search_path in Postgres

[dcro]

Following my bug report from #8639, the PostgresConnector class was modified to support a multi-schema search_path if the connection's schema configuration value is an array, e.g.

'connections' => [
    'postgres' => [
        // ... other options here ...
        'schema' => ['app', 'public'],
    ],
],

That fix does correctly set the search_path to the specified one but using an array instead of a string for the schema now produces an error in artisan migrations.

Running php artisan migrate now trows the following:

[Illuminate\Database\QueryException]
Array to string conversion (SQL: select * from information_schema.tables where table_schema = app and table_name = migrations)

The fix submitted with this pull request addresses this issue by using the first schema specified in the schema configuration array as the default schema for artisan migrations.

Users are still able to override this default schema if needed by specifying the schema in the migrations configuration options:

 'migrations' => 'public.migrations',

or by specifying a schema in the actual migration script:

public function up()
{
    Schema::create('public.users', function (Blueprint $table) {
        // ... migration ....
    }
}

[taylorotwell]

What is the purpose of using an array for the schema in your configuration file?

[taylorotwell]

Can you explain more about why the array would be used in the first place... is it supposed to fall back to the second schema?

[dcro]

Yes, it's basically a fallback as it sets the search_path in PostgreSQL to search multiple schemas. To quote the Postgres docs:

This variable specifies the order in which schemas are searched when an object (table, data type, function, etc.) is referenced by a simple name with no schema specified.

In 5.0 this used to work without an array but sometime before 5.1 it was modified due to issues with improper quoting and was later transformed to take an array which seems to work ok now, apart from the migration issues that are addressed with this pull request.

[taylorotwell]

So wouldn't the proper behavior be for it to check each schema in this case - not just the first one?

[dcro]

I think that actually depends on the use case:

Use Case 1

You want to check if a table exists in the specified search_path. In this case hasTable should indeed check each schema or simply avoid specifying a schema to let Postgres handle this on it's own.

Use Case 2

You do migrations and want to be able to create a table with the same name in multiple schemas.

For example in a multi-tenant app, where each tenant has it's own schema and there's also a defaults schema, you can use the multi-schema search_path as a fallback mechanism to some default table content while still having the option to override that default table with a tenant specific one.

My use case is actually the second one as I don't need to know if the table exists in other schemas since migrations are always performed in the primary schema (the first one). Also, based on the feedback from other users on #8639 it seems they also had similar use cases.

One possible solution to cover both use cases would probably be for hasTable to support both tables with schemas specified (hasTable('schema.table')) as well as tables without any schema (hasTable('table')). The first one would only check the specified schema while the second one would check all search_path schemas. The same would apply for Schema::create(), Schema::drop(), etc.

Let me know your thoughts on this and I can look into updating this pull request with such changes.

[taylorotwell]

I'll merge this for now and we'll see if the other use case arises.