While the sql reader syntax e.g. [select * table] is convenient for humans it doesn't allow for being used by other functions or does it?

(read-from-string "") as a last resort, otherwise it reads into a CLOS based AST anyways and that you can construct programmatically.

note: the SQL reader and AST stuff is on the TODO to be moved into hu.dwim.quasi-quote and rebased on its infrastructure. but it's not high priority, and wouldn't change anything conceptually...

In my opinion such a sql reader syntax is nice to have but not being able to extend the software through the use of functions is disastrous in my eyes. I have the feeling that we create two camps here, one the developers and the other the users. Personally I don't like that distinction and would

it's a library for developers, there are no two camps. it's only developers...

much prefer to make the possibility of extending the software through the use of functions as easy as possible for the so called "user".

With that in mind I find myself using internal function and classes from the hu.dwim.rdbms package ( e.g. sql-and, sql-sequence-nextval-column, sql-identifier, sql-all-columns, sql-= ) and writing wrapper functions for it e.g.

we didn't put too much effort into deciding what should be exported and be part of a long-time API, and what isn't. but while (not) doing that we were on the conservative side...

What do you think about what I just said. Did I go wrong somewhere? And if the above is really an issue, any ideas as how to handle it?

define your own convenience functions? if they seem to be generally useful, propose an extension (but to spare some time, the naming convention you use in your functions will not go though :)

Right now I did create another system and package called hu.dwim.rdbms.oracle.ext for things like the above. (The names above are not carved into stone tablets. I often change my mind before I settle for certain names and yes,  often the wrappers seem unnecessary but I don't want to change the package definition of hu.dwim.rdbms  and/or prefer shorter names.)

that's a good compromise and leaves you the freedom to use names/shortcuts you prefer. even if such utils were provided by the main lib, it would not please everyone... so the way to go is to provide a preferably complete skeleton of functionality using descriptive and sometimes long names, and let people do their shortcuts if the need be.

we stick to long names (and use fuzzy completion in slime).