fix(postgrest): Update parameter type of match() filter so that null values cannot be passed.

[dshukertjr]

What kind of change does this PR introduce?

Fixes #917

What is the current behavior?

Currently, users can pass null to match() filter.

What is the new behavior?

Users will not be able to pass null to match().

[Vinzent03]

This is technically a breaking change. A map may be of type Map<String,dynamic>, which is not assignable to Map<String, Object>. For example, if you type Map a = {"a": 4,"b":"String"} it's not assignable.

[dshukertjr]

I think we can still consider it a fix for a type that we didn't get right in the first place.

[Vinzent03]

But the type of a map may be easily Map<dynamic,dynamic> despite having no null entries. So a working code might break now. I would prefer to note it in the documentation and use an assert over the actual values instead.

[dshukertjr]

Fair enough 👍

[Vinzent03]

Might be good to undo this.

Suggested change

	query.forEach((k, v) => url = appendSearchParams(k, 'eq.$v', url));
	query.forEach((k, v) => url = appendSearchParams('$k', 'eq.$v', url));

[bdlukaa]

I like the first proposed solution better. It gives the developers type-safety, causing less hassle. It might be good to have this shipped in the next major release.

[dshukertjr]

I like the first proposed solution better. It gives the developers type-safety, causing less hassle.

I like it too. I think sometimes we try to be a bit too picky about what defines a breaking change. I feel like the world does revolve around these minor "technically breaking changes" being shipped as a bug fix all the time. Flutter itself ships "breaking changes" without bumping the major versions all the time, and as long as it's under moderation, I don't think we should hesitate to ship these changes.

I'd say we just ship it with the original change.

[Vinzent03]

I don't think you can compare Flutter breaking changes with package breaking changes. Packages should use semver, Flutter doesn't.
I'm pretty sure three are code basis, which throw a static analysis error now, which definitely is a breaking change. But sure, our other bug fixes may sometimes be more breaking, and they don't even show up when compiling.
I wouldn't make this breaking change, but you decide.