4 ms·

PostgREST's approach is not like PowerBuilder's. PowerBuilder didn't encourage you to know your DB ins-and-outs and use all of its features. It was DB agnostic

PostgREST's approach is not like PowerBuilder's. PowerBuilder didn't encourage you to know your DB ins-and-outs and use all of its features. It was DB agnostic and through its DataWindow you got a RAD way of doing CRUD for a desktop app but you still needed to add application logic in PowerScript. PostgREST on the other hand pushes you to know PostgreSQL. A more suitable analogy would be to something like Oracle Apex[1]. [1]:https://en.wikipedia.org/wiki/Oracle_Application_Express https://en.wikipedia.org/wiki/Oracle_Application_Express

AdieuToLogic 7y ago
> PostgREST's approach is not like PowerBuilder's. My intent was not to equate PostgREST with PowerBuilder, but instead to use the latter as a well-known example of a two-tier system. > PowerBuilder didn't encourage you to know your DB ins-and-outs and use all of its features. While PowerBuilder was "DB agnostic", as you identified, non-trivial applications relied heavily on RDBMS logic (stored procs, views, etc.). So while PB may not have "encouraged" RDBMS specific implementations, those which I encountered were never without. Granted, the client connection protocol vastly differs between the two offerings. Yet the system architecture is shared IMHO.