6 years later... but I have run into another flavor of this I'm wondering if the community or @twpayne have an opinion or experience with this.

I just ran into this problem when dealing w/ optional/nullable geometry types and the Value() implementation null pointer dereferencing.

It happens if you have a data model like so (example in postgres):

...
my_optional_point geometry(POINT, 4326)
...

and an equivalent go model:

type MyRow struct{
...
MyOptionalPoint    *ewkb.Point
...
}

So when using a pointer like this the Value method dereferences this here:

go-geom/encoding/ewkb/sql.go

Line 92 in c56c06d

if p.Point == nil {

Instead a small check would have to be added additionally such as:

func (p *Point) Value() (driver.Value, error) {
	if p == nil{
	    return nil, nil
	}
	if p.Point == nil {
		return nil, nil
	}
	return value(p.Point)
}

and shortening it (to leverage short circuit &&):

func (p *Point) Value() (driver.Value, error) {
	if p != nil && p.Point != nil {
		return value(p.Point)
	}
	return nil, nil
}

So while allowing the encoding to be nullable the entire pointer is not allowed to be nullable. I'm curious if this should be handled on the user side or the Value interface side. There is lengthy discussions on this topic.

encoding/wkb should support NULL values #92

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions