Nulls to zero values(again:)

[phoenix2x]

Hi there,

First of all, thank you for maintaining this amazing library.
We're trying to migrate to pgx from go-pg/bun library and noticed that pgx returns errors when trying to scan NULL value into go non-pointer value. After looking around it seems that the recommended approach is to always use pointers or special NullXXX types for nullable columns, which is probably fine. But before we jump into the rabbit hole of refactoring all our structs we'd like to give the approach described here #1242 a shot. After looking into the recommendations in this issue I was able to override for example integer codec to produce the desired behavior with this

conn.TypeMap().RegisterType(&pgtype.Type{
	Name:  "int4",
	OID:   pgtype.Int4OID,
	Codec: CustomInt4Codec{},
})

Unfortunately, it seems to be impossible to do the same for strings due to this switch

pgx/pgtype/pgtype.go

Line 1076 in dc94db6

case *string:

preceding overridable maps lookups. In other words, when a target is '*string' then 'scanPlanString' is always used and there seems to be no way to override it.

Due to lib complexity, I can't reliably say why this switch is needed but it does look like a leftover after some refactoring as all other types are handled in a more generic(overridable) way.

Is there anything else we can try to allow scanning posgres NULLs as go empty strings?

Thank you.

[jackc]

#1242 was written before v5 was released. The point of that code you are referencing is so the text format of every type can be scanned into *string without each type needing to specifically support that or even the type needing to be registered. Same goes for the *[]byte in the same switch statement.

However, this takes precedence over a registered type. This wasn't intentional so much as it never occurred to me someone would want to override simple text format to string behavior.

Moving that switch statement to the bottom of the function would resolve the issue. Unfortunately, when I tried it there were several test failures. So it appears a number of code paths are relying on this early text handling behavior. If those paths were all updated then I think it would be possible to support your use case.

[phoenix2x]

Thank you for the answer, I guess we'll have to stick with the NullXXX types for now. I might try to carve some time to submit a pr but not sure how complex the change might be.

[mdanialr]

Hi @jackc , is there any progress on this? and can you add an example as how to override such behavior please?

since in our company we deal with a lot of nullable varchar, but in our app, we only want to deal with pointer only if it's necessary also we have no concern about whether it's actually NULL or just empty varchar from database.

thank you.

[jackc]

I don't know of anyone working on this.

The only approaches now are to use *string or zeronull.Text directly.