Re: pgsql: Adjust interaction of CREATEROLE with role properties.
От | Andrew Dunstan |
---|---|
Тема | Re: pgsql: Adjust interaction of CREATEROLE with role properties. |
Дата | |
Msg-id | 6c20449e-ac9c-7876-0d90-70a1ddea1076@dunslane.net обсуждение исходный текст |
Ответ на | Re: pgsql: Adjust interaction of CREATEROLE with role properties. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Adjust interaction of CREATEROLE with role properties.
|
Список | pgsql-committers |
On 2023-01-26 Th 22:18, Tom Lane wrote: > Michael Paquier <michael@paquier.xyz> writes: >> On Thu, Jan 26, 2023 at 09:08:23PM -0500, Tom Lane wrote: >>> Is it worth checking for leftover regress_xxx tablespaces as well as >>> roles? >> Guess so. If this is to be applied to everything that fails under the >> naming restrictions, there could be a point in doing the same for >> databases, subscriptions and replication origins. Now the argument >> has less weight for these object types, surely, compared to roles and >> tbspaces. > By the time we've spun up a new backend, we might as well do more > than one query, so it seems like we might as well check everything > that's globally visible. > > However ... this'd only cover mistakes of this kind in the core > regression tests. Is there a way to cover contrib's installcheck > (without adding an additional psql run to each module's tests)? > > Maybe we need to enforce this at some other level than the tests > themselves, perhaps in pg_regress? > > Yeah, that seems like a better way to go. Then it would even apply to external project tests. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-committers по дате отправления: