Were there problems higher up in the web stack that required the functionality meta provides?
It is a lot easier to shoot yourself in the foot. You can do very destructive operations through meta. It's more powerful for doing useful things too. Just be careful.
HOWEVER, if they factored out their VIEWS component so that I can have a more grokkable version of INFORMATION_SCHEMA that's read-only, that sounds useful.
for development purposes using sinatra(ruby) and gin(golang) for http processing.
will check aquameta on monday
trying to more things from web stack inside the database, 80% of functionality in DB and 20% in web server and programming language.
I have completed these via plpgsql * api authentication * parse json request * generate son response * request / response logging * audit trail
WIP * routes * before, after filters * rate limiting * app configuration
SQL and particularly postgres' documentation go to great lengths to be very specific about what micro-behaviour you should expect when performing SELECTs, INSERTs, UPDATEs and DELETEs (Of major note the concurrency behaviour). Once you start operating on the schema all of these promises will go out the window.
So these "queries" would mostly behave as you'd expect, but not totally.
At best you'd have to fill the documentation with "oh except if you're operating on the schema..."s. At worst it could be horribly confusing to users.
