dpq2
dpq2 copied to clipboard
denizzzka
added support for all native user data types PostgreSQL 15
Hello, I have added support for all native PostgreSQL user data types (ranges, multiranges, network, bitstrings, geometry, xml and text search vector/query), for now except for multi-dimensional arrays and user-defined types. In order to add support for OidType.PointArray I had to explicitely distinguish between Point[] and Polygon by defining a solid struct Point in dpq2.conv.geometry. Please review and incorporate the changes in the code base on your sole discretion.
@llucenic Thank you!
In order to add support for OidType.PointArray I had to explicitely distinguish between Point[] and Polygon by defining a solid struct Point in dpq2.conv.geometry
Such case is need to cover by integration test
Denis, I do not understand fully your point regarding integration test. Is it possible you kind of fix the tests yourself?
It is common practice to immediately implement a test with a PR, yep? Is there some problem with this?
Tests can be added into native_tests.d file.
I have corrected the code, so that it passes at least some of the check jobs. However, the rest of the failures are beyond the scope of my PR.
At the moment, I cannot do much more. Maybe later, and I am not sure though the code I added follows your design of the library. Therefore I have asked you to add the tests yourself while integrating the changes into your code base.
Maybe implementation of ranges as a separate PR would be the best solution. Otherwise this PR is too big.
However, the rest of the failures are beyond the scope of my PR.
Yes, looks like this issues itroduced by new compilers and will be solved not in this repository.
But I am worry about lack of integration tests for ranges. This is fundamentally new structures, I would like to cover with tests at least one of each base type.
If it is too difficult feel free to copy and paste here your actual code what works with it and I'll try to implement test by myself
If integration tests for ranges are what makes you integrate this PR in your library, then I think I can provide them. Assuming that we avoid splitting this PR, which does not make much sense to me (as implementation of ranges is only code in conv/ranges.d).