Alternative implementation for JSONCodec.PlanScan#2236
Conversation
|
I will add a test to prevent regression from #2229 and look at failing tests tomorrow. |
|
@jackc Looking at the following examples, I believe that the current scanning behavior is in inconsistent. type Foo struct{}
var dst *Foo
err = conn.QueryRow(context.Background(), `select 'null'::jsonb`).Scan(&dst)
// err == nil
// dst == nil
var dst *Foo
err = conn.QueryRow(context.Background(), `select null::jsonb`).Scan(&dst)
// err == nil
// dst == nil
var dst Foo
err = conn.QueryRow(context.Background(), `select 'null'::jsonb`).Scan(&dst)
// err == nil
// dst == Foo{}
var dst Foo
err = conn.QueryRow(context.Background(), `select null::jsonb`).Scan(&dst)
// err == can't scan into dest[0] (col: jsonb): cannot scan NULL into *pgx_test.Foo
// dst == Foo{}I believe either both cases of scanning |
be231da to
b62ce75
Compare
|
I decided to revert #2151 partially. This is because this should never be necessary, as such cases would be handled by the |
75289ac to
a5353af
Compare
|
Thanks! |
|
@jackc Can we add this to the next patch version v5.7.3 please as v5.7.2 has the regression when scanning null jsonb columns into a pointer? |
|
@emreisikligil Just released v5.7.3. |
|
@jackc Thanks a lot 🙏 |
|
Just as a FYI, this did change the behavior of scanning a constant this now fails in 5.7.3 with: The test passes on 5.7.2. |
|
|
||
| func (s *scanPlanJSONToJSONUnmarshal) Scan(src []byte, dst any) error { | ||
| if src == nil { | ||
| if src == nil || string(src) == "null" { |
There was a problem hiding this comment.
This is due to this change. Which was made with #2236 (comment) in mind, however looking at the godoc for the json package, not erroring is intentional. Though I personally don't agree with the rational, it's probably for the best to revert this change.
// The JSON null value unmarshals into an interface, map, pointer, or slice
// by setting that Go value to nil. Because null is often used in JSON to mean
// “not present,” unmarshaling a JSON null into any other Go type has no effect
// on the value and produces no error.
There was a problem hiding this comment.
I agree. I think this should be reverted.
There was a problem hiding this comment.
Thanks both for the quick reply, and many more thanks for a great library.
Revert change in `if` from #2236.
The fix from #2151 just pushed the original problem from #1470 and #1691 further along. This should be a comprehensive solution; also resolves #2229.