Description

I tried to build my own SQLC plugins and I had multiple ideas to make sqlc more user friendly for other teammates. And more inline with usual ORM feature set.
But I run into few limitations, and realized current plugins have only limited ability in their current form.
So I would like to know if there are some know solution to some of these issues and open a discussion around this subject.

1. More Parsing Information

Generating query automatically works fine, but it's made really hard because of the lack of some key informations from the schema (primary, foreign, index, constraint, unique, comments, ...).
I tried but was not able to access any of these information, and it remove the ability to build a graph representation of the database and understand relations between tables. One of my idea was to use mermaid to generate a DB diagram from the schema, but I couldn't make it work as expected without relations informations.

If at least plugin had access to the original schema, they could reparse data the way the want without modifying sqlc too much.
Obviously a more integrated solution would be better.

2. Modifying generated queries

Other idea, I also wanted to work on a soft-delete plugin:

• have a field deleted_at on some tables
• need to modify existing select query to add a WHERE deleted_at IS NULL clause automatically

But it looks like plugins by design are standalone and generate their own output. So they don't seem to be able to modify generated output by sqlc or another plugin. Am I wrong?

3. Modifying generated code

Another idea, I was thinking about a audit-logs plugin to automatically logs activity on specific tables (let's say customer). Some kind of hook or middleware function executed with every query function generated (before/after).
Such ability would be also useful for something like caching, without putting it everywhere in the code.

Example: Prisma Middleware

But I couldn't find a way to do that, is it possible?

4. Modifying schema

This one is probably the hardest of the list, because it break some existing flow (like using migration tools).

For some plugin, it could be useful to be able to modify the original schema on the fly before code generation. Example:

• add new tables, like a i18n plugin which create translations tables on the fly
• create new fields, like pre-computed fields for search (with trigger queries)
• modify existing field type before code generation, to allow compatibilty between different database, so a postgres schema could be rewritten on the fly into sqlite schema for testing purpose