-
Notifications
You must be signed in to change notification settings - Fork 4
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
custom pointer to struct type scan issue #6
base: master
Are you sure you want to change the base?
Conversation
stat := &Stat{ | ||
Key: "count3", | ||
Num: dbtype.NewBigIntFromString("44", 0), | ||
Rating: &bv, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
passing *dbtype.BigInt here is causing an assignment issue to a nullable NUMERIC(78,0) type
ID int64 `db:"id,omitempty"` | ||
Key string `db:"key"` | ||
Num dbtype.BigInt `db:"big_num"` // using NUMERIC(78,0) postgres datatype | ||
Rating *dbtype.BigInt `db:"rating"` // using NUMERIC(78,0) postgres datatype |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is the problematic runtime type, of *dbtype.BigInt .. resulting in the error on rows.Scan(..) of:
=== RUN TestRowsWithBigInt
(*dbtype.BigInt)(nil)
pgkit_test.go:379:
Error Trace: pgkit_test.go:379
Error: Received unexpected error:
pgkit: scany: scan row into struct fields: can't scan into dest[3]: unable to assign to *dbtype.BigInt
Test: TestRowsWithBigInt
pgkit_test.go:382:
Error Trace: pgkit_test.go:382
Error: Should be true
Test: TestRowsWithBigInt
// return fmt.Errorf("cannot assign %v to %T", src, dst) | ||
// } | ||
|
||
func (b BigInt) DecodeText(ci *pgtype.ConnInfo, src []byte) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can ignore this method, it was just me doing some hacking code. I was thinking that if pgx cannot support a null value of a normal database/sql scanner+valuer, then we can try the add binary encoding support here which might solve our issue in the end.
Alternatively, maybe there is another way to make pgx or scany work, and if not, finally we could adapt pgkit instead of using the pgx-direct driver, we update all of pgkit to use the database/sql interface which pgx also supports. I'm not sure exactly what we'd compromise by not using pgx-driver directly anymore, but it would be nice to know that too if we decide that..
I think this is related to jackc/pgx#1000