dbal: Postgres: public should not be considered a "application schema" and should be ignored the same as other system schema from `getSchemaNames`

Indeed, I’ve taken a look, and although it could be fixed in the ORM by tweaking SchemaTool::getSchemaFromMetadata(), that would make ORM schema creation attempt to create the public PG schema.

I see that DBAL has a schemaAssetsFilter configuration node, which I could not find documentation on but seems to be about making the DBAL ignore assets it should not manage. This leads me to formulating the following problem:

While it is possible to filter out assets in a schema, it’s not possible to filter out schemas in a database.

A solution could be to add another configuration node just for this, and let the user configure it. That way we don’t need to make any assumptions about what the user thinks about public. Assumptions should be made in Symfony recipes. That assumption should be made here, in the form of a commented out configuration node.

“everybody assume that it is present” doesn’t have a proof

1. postgresql default value for search_path is public , so if you drop public select * from articles will break
2. postgresql documentation states that By default such tables (and other objects) are automatically put into a schema named “public”. Every new database contains such a schema. https://www.postgresql.org/docs/current/ddl-schemas.html#DDL-SCHEMAS-PUBLIC so it read as … well “it is present in every new database” , i don’t know where’s the subjective interpertration you can
3. doctrine migrations breaks if you drop the public schema because it is the default one it uses

I’m really sorry but what kind of proof more than that do you need , if I rephrase it as "major projects, including the database itself use it as a default value because except if you’re doing very specific stuff, it will be there " would a more objective statement ? if not how do you describe my points ?

also what’s really frustrating is that these points are from my above comments, I really took the time to gather them, and you decide to discard them

i feel a bit disappointed , the stated issues are clear not a opinion, the “opinion” is a consequence of these issues, not the other way around,

it doesn’t state an objective problem.

facts:

• right now dbal can not handle dropping schema
• right now dbal always report it will create the public schema (causing the “issue in an other repo” it’s because it’s the only repo using this feature in a way that is tangible for the end user , it does not take a long time to see doctrine migration is just doing a very thin layer on top of this, so there’s no way to fix it except here) making people needing to edit their down migration to remove it

when you tried to consider public as a normal schema while adding the possibly for dbal to report SQL to drop schema , you had issues

as a consequence of that i see that the way to solve this is to consider public as special schema

I’m not some kind of militan that think public should be considered special out of the blue and here find a way to spread my propaganda , i’m just a pragmatic people who try to find solution to problem

so please first discard the facts before focusing on the proposed solution

It’s only because it’s in the user’s/session’s search_path.

thanks for pointing that out, I was looking if it was overridable and it was right under my nose.

However my other point still stands and this one is slighltly amended , as in the case of a DBA requesting the search_path to be overrided to avoid accidental use of publc , it means even more that public should not be touched at all by the application layer