Replies: 1 comment
-
Starting v0.16, the SQL API will evolve in the following directions:
We are using both Postgres and SQLite as reference implementations but will always have a preference towards Postgres when the API differs. However, the goal is not to have 100% feature parity with Postgres (I mean, it's Postgres), or even 100% the same API on features that we manage to implement.
Short answer: yes, mostly. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I mean, between Postgres and MariaDB and Oracle and SQL Server there can be wild SQL syntax / expression variations for various constructs. I'm curious what this project is shooting for basically.
In other words: "will an ORM supporting PostgreSQL likely overwhelmingly work well, excepting (list of non-supported things here... eg. on-update triggers?) — or does it also need to have an SQL-generator for eg. SQLite too?" What's your "SQL basis"?
Let's assume we're talking not just CRUD but also
create table
,create index
(if even applicable?)Thanks already, really eyeing a giving this a spin instead of CGO SQLite!
Beta Was this translation helpful? Give feedback.
All reactions