-
Notifications
You must be signed in to change notification settings - Fork 802
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for pgx #472
Comments
We currently use PGX and its batching mechanism. Would be great if you keep pgx batching in mind while this unfolds. |
@ldelossa Do you have an example of the batching API? This is the first I've heard of it |
@kyleconroy we wrap it a bit to handle variable sized input: usage: |
pgx is new to me, so I wanted to spend some time getting the driver working for the example in Some learnings:
|
Awesome! It would be cool to support decoding composite types at some point. It's pretty tedious to implement |
In the booktest example at least, the |
Do you really need to support pgtype... There are a lot of times you don't need it.. and pointer to native type is enough. This also means that you can use the same struct through most application and there is no need to convert between db struct and "domain" struct. The onl conversion is then for viewing purposes. |
Thanks for the feedback @mvrhov! I was able to get my test cases working with some native go types and the pgx driver interfaces. Also, just discovered that sqlc only implements 1-dimensional array types, so that will help keep things simple. 👍 |
I noticed we're still using |
Does this mean that you are planning to support pgx native interface i.e. pgxpool? |
pgx/stdlib works well already. |
@georgysavva the plan is to support pgx/stdlib first, and then add support for pgxpool. |
@kyleconroy Thanks for explaining. |
Hey guys! @kyleconroy do we have any updates on this? I've just hit this wall unfortunately. Edit: I'm creating a fork right now with a colleague and we'll try to work this out for our case ( |
Hey everyone, just in time for christmas I ended up doing something that worked out fine for me. You can check what's different in this diff. Usage remains equal, except that you need to inform a new parameter at the startup configuration yml file, as in version: "1"
packages:
sql_library: "pgx/v4" If this parameter is missing it defaults to the old behavior. Currently only supporting :one, :many, :exec (still need to implement others commands and tags) I'm not very fond of this name I've used but couldn't think of anything better at the time. From my restricted testing everything looks fine to me, however I didn't do anything fancy yet. Maybe this could be a start. Edit: to check it yourself, download my fork, switch branches to |
@kyleconroy and others: even though the above fits my use case (which is indeed very simple at this moment) it still is very premature in many aspects to even consider opening a pull request. Despite that, do you think the changes made here are heading in the right direction? If so, we could maybe merge this on a new development branch and continue work over there |
Just following up here - found another data race in lib/pq and it would be great to have a chance to evaluate other drivers, but at the moment we're pretty tied to using sqlc. |
@kevinburkemeter pgx/stdlib works ok with sqlc. |
working on that. is there a currently supported way to replace |
afaik you don't need it for standard types. |
|
|
Did #1037 replace the use of |
@johanbrandhorst Is it possible to generate |
I don't think is it, yet. |
Get out the trumpets and ready the 21-gun salute,
lib/pq
is deprecated (#470). This means it's time to support it's successor, pgx.This will be the main tracking issue for pgx. It supersedes #28, as I have no intention of adding support for any additional PostgreSQL drivers beyond pgx.
The text was updated successfully, but these errors were encountered: