Remove unknown pgtype dependency #5596
Conversation
improves object parameter resolution cache re-use when writing nulls and non nulls as well
7c1d61e to
a4526a7
Compare
| public void DBNull_reuses_type_info([Values]bool generic) | ||
| { | ||
| // Bootstrap datasource. | ||
| using (var _ = OpenConnection()) {} |
There was a problem hiding this comment.
nit: move to a fixture initializer ([SetUp])?
| using (var _ = OpenConnection()) {} | ||
|
|
||
| var param = generic ? new NpgsqlParameter<object> { Value = "value" } : new NpgsqlParameter { Value = "value" }; | ||
| param.ResolveTypeInfo(DataSource.SerializerOptions); |
There was a problem hiding this comment.
Ideally we'd test public behavior rather than internal functions, but not super important.
There was a problem hiding this comment.
I debated whether to add these tests. Given they impact edge-cases in the binary importer I decided it's worth making sure these internal contracts (GetResolutionInfo/SetResolutionInfo) keep working correctly.
| public string DisplayName => | ||
| Value.StartsWith("pg_catalog", StringComparison.Ordinal) | ||
| Value.StartsWith("pg_catalog", StringComparison.Ordinal) || Value == Unspecified |
There was a problem hiding this comment.
In which situation will DisplayName actually get called for Unspecified?
There was a problem hiding this comment.
Mostly for completeness. Though you could do NpgsqlParameter() { DataTypeName = "-.-" }, try to write it, resolver won't find a match, and we'll create an error message containing the displayname.
Adding a case for Unspecified means we return "-" (which matches pg) vs "-.-".
|
@NinoFloris just putting a reminder here to backport in case you forget. |
|
Backported to 8.0.3 via 6201e1b |
Brings our compat with pg-likes back to <= 7.x levels.
These changes also improve object parameter cache re-use when writing db nulls and non-nulls of a constant type via the same parameter instance. This will feed into improvements to binary importer perf in a later pr.
Fixes #5503