Features I wish PostgreSQL had as a developer
bytebase.com
Features I wish PostgreSQL had as a developer
1–10 of 65 posts
Re: Features I wish PostgreSQL had as a developer
#2> The typical way to do schema migration is to compose a list of ALTER TABLE statements. This becomes hard to track the latest schema state as the migration accumulates. It's more intuitive for the developers to specify the desired state. Ideally, PostgreSQL could allow developers to specify the desired CREATE TABLE schema, the engine then reconcile it with the latest schema, figure out the diff, and plan the migration path internally.
This is a terrible idea. The behaviour of engines that do this is unpredictable and suddenly you lose data because the engine deleted a column.
Re: Features I wish PostgreSQL had as a developer
#3Add to the list: Ability to reorder columns :)
Re: Features I wish PostgreSQL had as a developer
#4> Archived Table
> To prevent deleting data by mistake, we invent soft-delete pattern by having a is_deleted column. However, this brings extra complexities around foreign key, unique index enforcement. Ideally, PostgreSQL could allow users to configure an archived table. The removed data is moved to the archived table first and purged after a configured retention period. This simplifies application logic and data compliance work.
Partitioned tables works pretty well for this. https://www.postgresql.org/docs/current/ddl-partitioning.htm...
Re: Features I wish PostgreSQL had as a developer
#5Add to the list: Ability to reorder columns :)
Genuinely curious, why is this an issue? I don't think I've ever looked at a table and thought "oh, it'd be nice if I could move these around a bit".
Re: Features I wish PostgreSQL had as a developer
#6Interesting list. I think the items related to schema migrations are probably bad ideas, as the logic and process around even simple schema migrations can be extremely complex and varied. It seems much better to keep this as an external component than to build features into the db engine around a narrow set of approaches.
I like several of the other ideas, though. Branching is at least partially implemented in other RDBMSes. MS SQL Server has been able to do instant read-only database snapshots (which capture a point in time and can be queried just like the original DB) for decades.
Re: Features I wish PostgreSQL had as a developer
#7Add to the list: Ability to reorder columns :)
Genuinely curious, why is this an issue? I don't think I've ever looked at a table and thought "oh, it'd be nice if I could move these around a bit".
space/storage optimization
Re: Features I wish PostgreSQL had as a developer
#8I'd like to see an option for automatically adding indexes for performance.
Perhaps a background process could re-run the query planner for frequent queries and add an appropriate index if there's a big speedup.
Re: Features I wish PostgreSQL had as a developer
#9I'd like to see an option for automatically adding indexes for performance. Perhaps a background process could re-run the query planner for frequent queries and add an appropriate index if there's a big speedup.
As a developer who is not a DB expert, I always wonder why index cannot be auto added based on queries may be ? So lets say I have a table and once it starts filling in data and sees the typical queries coming in (say based on user id or email etc), just add the index ?
Re: Features I wish PostgreSQL had as a developer
#10> The typical way to do schema migration is to compose a list of ALTER TABLE statements. This becomes hard to track the latest schema state as the migration accumulates. It's more intuitive for the developers to specify the desired state. Ideally, PostgreSQL could allow developers to specify the desired CREATE TABLE schema, the engine then reconcile it with the latest schema, figure out the diff, and plan the migrati…
It’s not inherently a bad idea, though. I do agree it would likely be poorly implemented.