René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Project Future","articleBody":"Occasional maintenance and house keeping will be performed. However, this project is not subsidized and interfaces like [PostgREST](https://postgrest.org) and [asyncpg](https://github.com/MagicStack/asyncpg) are more appropriate solutions in many cases. \"syncpg\" probably maintains some value with its pure-Python convenience, but that utility is likely niche even if `psql` scripts were the only alternative. I would find a way to make an async py-postgresql work, but...\r\n\r\nLong term, I don't really see the value of the PQv3 protocol versus an HTTP based solution (as a PostgreSQL built-in or a PostgREST-like layer). Leveraging PUT/POST/QUERY methods to virtual resources easily handle connection/transaction local resources like statements and cursors. One shot queries to (database) system views or functions could fulfill any introspection requirements if custom headers and HEAD methods were insufficient(PQ Describe* messages). The HTTP Accept header could be leveraged to select the desired format of a response: tsv, csv, json, etc. UDFs could extend the set of supported formats and additional (HTTP) interfaces. QUERY methods submitting SQL statements to an allocated transaction resource. etc.\r\n(Some of this is probably implemented by PostgREST, but I'm unfamiliar with its feature set. I'm just itemizing a small subset of the obvious.)\r\n\r\nHTTP can do all the things over reliable data streams (tcp/v1-2) and unreliable messaging channels (quic/v3).\r\n\r\nTwenty years ago, this view would have been suspect, but with the ubiquity of HTTP and JSON. PQ is often just overhead.","author":{"url":"https://github.com/jwp","@type":"Person","name":"jwp"},"datePublished":"2023-02-10T18:04:10.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/124/fe/issues/124"}