Implement scanner for range/array for postgresql types

[Micrococonut]

I was migrating my project to v5 today and I hit a roadblock. I was trying to move from Tstzrange to the Range[Timestamptz] generic interface but my tests were failing with:

name "systime": unsupported Scan, storing driver.Value type string into type *pgtype.Range[github.com/jackc/pgx/v5/pgtype.Timestamptz]

for my struct

type TelemetryMapHistory struct { HistoryID uint 'gorm:"primarykey"' Systime pgtype.Range[pgtype.Timestamptz] 'gorm:"not null; type:tstzrange"' ... }
So I did some digging and found that the Range type does not implement the scan interface.

so I made my own type and implemented it myself and it works.
type Tstzrange pgtype.Range[pgtype.Timestamptz]

It seems as though this has been asked for in the past (#2421) but was denied due to upcoming golang changes (#2403) which are now no longer happening. Am I doing something wrong here? Is it expected that any users who want to use range types have to implement these functions themselves?

[jackc]

Am I doing something wrong here? Is it expected that any users who want to use range types have to implement these functions themselves?

Implementing Scan for the types you need is a perfectly reasonable approach for the time being.

My long term hope is still that some form of the Go change still lands and these types will eventually work directly. The other option is using pgtype.Map.SQLScanner. The reason Scan was not directly implemented was I was unable to figure out a good way to make that work with generics.

[Micrococonut]

The reason Scan was not directly implemented was I was unable to figure out a good way to make that work with generics.

IMO every built-in type should have their own formal type defined in pgtypes.

int4range
int8range
numrange
tsrange
tstzrange
daterange

Are all built-in types. The generic Range type is cool for supporting user-defined range types, but I don't see why not just keep the discrete types for built-in types. When I was messing around with my migration trying to figure out what happened between v4 and v5 I just made a type alias type Tstzrange Range[Timestamptz] and implemented Scan on Tstzrange. Is there a reason you do not want pgtypes to define built-in types in this way?

[jackc]

Is there a reason you do not want pgtypes to define built-in types in this way?

It seems more elegant to me to use the generic types, especially if/when Go finally gets a change that allows it to be used directly. I'd rather not add 50+ types only to deprecate them later.

It's not such a big deal for Range as there are only a handful of types and user defined types are more rare. But the same pattern holds for Array where there are 50+ types as well as users frequently define their own types.

I suppose I wouldn't mind having a separate package that contains these types that are useful for database/sql. But I'd rather not get permanently stuck with them in the pgtype package.