3 ms·
When I was a lad embedded SQL - like Oracle's Pro* C - was the thing, i.e. a C program with EXEC SQL blocks containing actual SQL, which was then run through a
by tragomaskhalos 11y ago
When I was a lad embedded SQL - like Oracle's Pro* C - was the thing, i.e. a C program with EXEC SQL blocks containing actual SQL, which was then run through a precompiler to convert into proper C with API calls.
Nowadays this technology seems almost completely forgotten, and I confess to being baffled as to why. Certainly existing implementations are execrable - just read up on indicator variables, or string handling, in Pro* C to see what I mean, but IMO the concept is sound if married to a modern 'host' language like C++ or Rust. One very strong advantage is that you are then actually writing your SQL in SQL, not using some baroque builder API.
As for typing, the precompiler could parse the SQL and see what result sets are being returned / what columns are being married to bind variables and so on, and then interrogate the database's metadata to determine their types. AFAIK no existing implementation does this.
- baq 11y agothis approach doesn't allow you to easily compose queries; you've got a SQL world and an application world which are mostly incompatible. here, you can easily stitch together the query you want while being free of worrying about SQL syntax correctness.
- tragomaskhalos 11y agoHorses for courses; if you have a lot of very vanilla SQL then sure, and this is clearly a very common use case because these sorts of APIs are very common now (aside: although often there's an argument for going straight to an ORM). On the other hand in a data-centric application that is exercising the database quite hard I want to be working in SQL directly, eg so I can try it out outside my code, and I don't fancy digging through a builder API document to see how (or if) I can hint an index, or use a CTE, etc.