RowToStructByNameLax should not error if a field exists in the resultset that doesn't exist on the struct

[logicbomb]

Say I have a table

create table Foo ( id serial, name text, color text)

and a model

type Foo struct {
  id int  `db:"id"`
  name string `db:"name"`
}

And I want to query and hydrate the model

  rows, err := conn.Query(ctx, "select * from Foo where id  = $1", ID)
	defer rows.Close()
	if err != nil {
		return nil, err
	}

	c, err := pgx.CollectOneRow(rows, pgx.RowToStructByName[Foo])
	if errors.Is(err, pgx.ErrNoRows) {
		return nil, nil
	}

Currently this gives the error struct doesn't have corresponding row field color (on lines 727-732 or rows.go). The example code is trivial, but, in a table with multiple columns where a few may not be selected it's annoying to have to explicitly list each field, it's much easier to issue a select * query.

I guess the reasoning is that the software should select only the fields it needs, but, that seems like a decision that should be left up to the dev. Would you be willing to accept a PR to address this?

I was thinking to use the lax field and push it down to the lookupNamedStructFields function, when lax = false the current behavior is used, when lax = true this method would ignore fields where f.path == nil

[jackc]

The example code is trivial, but, in a table with multiple columns where a few may not be selected it's annoying to have to explicitly list each field, it's much easier to issue a select * query.

The DBA in me cries a little here. 😢 😉 While select * is convenient, IMO, it is rarely wise to use it in production code.

But beyond this, as an application developer, this proposed change also unsettles me. With the existing lax behavior, you at least know all columns returned from the database were matched to your struct. But with this typos or mismatched names would silently fail. You would have a zero value you weren't expecting. That seems dangerous.

[logicbomb]

What typos would cause silent failure? Currently typos in either field tags on the struct, or in the list of fields in a select statement will cause a runtime error, I don't see what changes with this new method of lax processing.

With the existing lax behavior, you at least know all columns returned from the database were matched to your struct.

That's sort of the behavior I'm having trouble with :D, having to list 17 of the 18 columns I'm selecting is the nuisance / maintenance overhead I'd like to avoid.

[jackc]

With the existing behavior given this struct:

type T struct {
	Foo string
	Bar string
}

Then this SQL query will currently cause an error:

select foo, baz from t;

Because the database column baz is not matched to any struct field. With this change there would be no error and struct field Bar would be left at the zero value.

[logicbomb]

I didn't consider the un-annotated case. Ok, well, I'll defer to your judgement on this. I appreciate the amazing work you've done on the library. Thanks for talking it through with me.