Support Postgres on native targets
See original GitHub issueDescription
I want to use sqldelight with Postgres on Kotlin Native. I wrote my own Postgres Native driver (could be moved to sqldelight if stable and wanted).
But the current postgres dialect uses JDBC references, runtimeTypes
and PostgreSqlType
.
Idea: Make PostgreSqlDialect
open to support override runtimeTypes
without writing the postgres dialect from scratch. Refactor PostgreSqlType
to an interface to support 3rd party implementations as well.
Issue Analytics
- State:
- Created a year ago
- Comments:5
Top Results From Across the Web
Using a PostgreSQL database as a target for AWS Database ...
Use a PostgreSQL database as a target for data migration using AWS Database Migration Service.
Read more >15.7. Platform-specific Notes - PostgreSQL
Platform-specific Notes. This section documents additional platform-specific issues regarding the installation and setup of PostgreSQL.
Read more >PostgreSQL Requirements - HVR 6 Documentation - Fivetran
HVR requires that the PostgreSQL native LIBPQ (i.e. libpq.so.5 and its dependencies) is installed on the machine from which HVR will connect to...
Read more >Is PostgreSQL on Amazon RDS supported as Source/Target ...
PostgreSQL on RDS is supported as Source/Target in PowerCenter 10.4.x although it is not mentioned in the PAM as well as in the...
Read more >Near zero-downtime Postgres migrations and upgrades with ...
The goal of migrating a database is to create an identical copy of it on a ... Both Postgres' native logical replication and...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
(If you’re wondering why we do that - we need the whole dialect to be loadable as a single jar for the IDE functionality to work, and we can enforce non-transitivity a lot easier in gradle)
Thanks, worked!