Why does a developer(?) need to create his own tables in a production(?)
database?
On 11/7/22 11:28, Erik Wienhold wrote:
I want to get some feedback on the idea of allowing users to create objects in
a database whose schema is already managed with version controlled migrations.
One of my team mates is displeased with our setup because he cannot create his
own tables without bypassing version control. This is a bad idea IMO even if
it's technically possible to give users a reserved shared namespace that is
never touched by versioned migrations.
The following issues come to my mind. Issues 1 and 2 are solvable while issues
3 and 4 are just sources of unnecessary frustration on my part.
1. There are multiple users each with a dedicated database user. Consequently,
table owners will vary but those tables should be accessible to any user.
The only solution I can find (besides giving superuser privileges, yikes!)
is to use an event trigger on ddl_command_end to handle CREATE TABLE and
change ownership to a group.
Is there something like CREATE SCHEMA AUTHORIZATION which applies to objects
created afterwards with separate DDL? Or just leave the owner as it is and
resort to DEFAULT PRIVILEGES instead?
2. Users must not create views and procedures that depend on objects managed by
versioned migrations. Otherwise migrations may fail or break procedures
unexpectedly due to untracked dependencies. Event triggers can prevent that
as documented for table rewrites[1].
3. Reinventing the wheel and data duplication if anyone can haphazardly create
new objects. It is also difficult to enforce best practices in that case.
4. Harder to reproduce bugs if the complete database schema cannot be recreated
from version control.
My background is in web applications where you have a nice separation of
database layer and application layer. In our case, users work directly with
a PostGIS-enabled database via QGIS and pgAdmin, hence the "need" (or wish) to
create own tables because it looks like a quick and easy solution to them.
I still have to accustom to this setup where people directly access the database
instead of having a layer of abstraction in top.
Has anybody experience with such a setup? More arguments against it are
appreciated. Solutions are also welcome.
[1] https://www.postgresql.org/docs/15/event-trigger-table-rewrite-example.html
--
Erik
--
Angular momentum makes the world go 'round.
