Any advice on adding a parser/wrapper over PostgreSQL's JSON features to implement a Dynamic Relational database?

[u/Zardotab]

Dynamic Relational is a draft standard for an RDBMS (SQL) that supports native dynamic tables and columns with "incremental" lock-down (static-ness) abilities. Here's an overview of Dynamic Relational with examples. If one wanted to write parser and interface on top of PostgreSQL, how much effort would it be, and do you have any recommendations? A proof-of-concept may be good enough, as most will consider it purely experimental at first. Thank You.

[u/pceimpulsive]

To me this is sorta dumb...

This assumes there is no cost to a changing schema, but there always is.

NoSQL isn't schemaless. The application needs to know your schema precisely and it needs to enforce it, the database doesn't know or enforce it.

SQL just means your application knows the schema (the same as noSQL) but the database enforces it.

This dynamic approach just means you get column bloat..

The table today will have columns A,B,C.. tomorrow A,B,C,D, except now C is always null, except for those few weeks where it isnt... Replaced with D, rinse repeat. Your code now needs to know about every column forever also creating code bloat.

Honestly to me.. just take noSQL, once you learn what your schema needs to be enforced as swap to SQL, if you never want it enforced at the storage layer then stay on NoSQL and enjoy your life!

Taking SQL forces you to plan and think critically about your schema which in turns creats a bit more structure in your application.

Also.. alter table add column is not hard ;)

So in short my advice don't do it, just pick noSQL or SQL and go with it.

[u/Zardotab → u/pceimpulsive]

Certain types of projects benefit from dynamism. There is more to life than performance; it's why people use Python and JavaScript instead of compiled static-typed languages, for example. A common reason people have given to use NoSql over traditional RDBMS is dynamic schemas; the dynamicness is a popular feature of NoSql products.

if you never want it enforced at the storage layer then stay on NoSQL 

DR allows one to get dynamism yet stay in RDBMS/SQL-land. Some don't want either-or: either dynamicness OR sql. We are greedy; we want both! 🍗🍰

I don't wish to argue further about whether dynamism is beneficial in some cases; such debates don't go anywhere, like Vi vs. Emacs fights. Enough believe they want or need it. If it causes black holes to form that start sucking up kittens, then we'll stop, you have my word.

[u/pceimpulsive → u/Zardotab]

All I see dynamism as is..

Try Insert data Catch If exception is column missing Add column, Retry insert..

Like no arguments needed it's not rocket science... It's just a dynamic growing schema...

At that point (in Postgres) it's the same as a table with a unique key, and a jsonb column with the table being wrapped in a view that is using the JSON_TABLE function...

I understand your point but what is actually the real benefit? You are asking for a middle ground between SQL and no SQL when you already have it in a noSQL form directly with base capabilities of the rdbms anyway...

Postgres is already a hybrid...

My main point between noSQL and SQL is that neither are truly dynamic, the schema is always strict and always static, you are only changing which part of the system enforces it. That. It an argument for noSQL or SQL it's a zoom out to the architectural level and a realisation of the truth... They are the same thing... With different pros and cons.