Is your feature request related to a problem? Please describe.
I build a lot of projects that always have a database as part of the stack and I've chosen Jet in my constant pursuit of type safety haha. Over time I've developed a small library for my organization that contains frequently reused code snippets built on top of Jet. Thing is, I've had to do a really frustrating separation where I have a separate package for MySQL and PostgreSQL despite the code between the two packages being literally identical, just different types. For instance, I have a tiny wrapper function that checks if a column list contains a particular column:

// MySQL implementation
func ContainsCol(cols mysql.ColumnList, col mysql.Column) bool {
	return slices.Contains(cols, col)
}
// PostgreSQL implementation
func ContainsCol(cols postgres.ColumnList, col postgres.Column) bool {
	return slices.Contains(cols, col)
}

Now I won't lie, this particular wrapper is kind of useless. It's a hang over from before my projects were running on a newer version of Go that included the slices.Contains function, but it's a good, succinct example of the problem I'd love to see solved. That's the exact same piece of code, just different types, except both of those types frustratingly enough point to the exact same type in the internal jet library (jet.ColumnExpression and jet.ColumnList respectively).

Describe the solution you'd like

It would be awesome to have a tiny, shared library that exports basic shared types that are exactly the same between dialects. Things like jet.ColumnExpression and jet.ColumnList. Of course I know this is somewhat subjective as there are dialects that have different types or different underlying structures, so I know some dialects will diverge from others, but that's something that type safety can keep in order naturally. If a particularly complex dialect diverges from the underlying jet.ColumnExpression, then Go can keep in order whether or not the column type from that dialect still suitably implements jet.ColumnExpression for use in shared code.

I'm sure there are other edge cases that might make this infeasible at a full scale, but it would be awesome to just have a small selection of the most commonly shared types available.

In the meantime, I'm going to opt to introduce a local column type that just inherits from mysql.Column and postgres.Column, but I don't really like this on account of obvious potential breakage if these types diverge in the future and extra weight of importing Jet's postgres and mysql libraries all the time, despite only one being relevant.