Support maxdecimaldigits option by geometry type

[alexile]

Description of change

Adds support of PostGIS maxdecimaldigits option. The value comes from the existing precision option. Currently, it isn't possible, so the precision is always 9, therefore small, detailed elements either overlap or cannot be found using ST_Intersects, ST_Overlaps, etc. By default, PostGIS rounds all decimal places beyond maxdecimaldigits, which causes precision issues/ruins searching. This PR makes precision not only affect double but geometry types as well.

Fixes #7165

Pull-Request Checklist

• Code is up-to-date with the master branch
• npm run lint passes with this change
• npm run test passes with this change
• This pull request links relevant issues as Fixes #0000
• There are new or updated unit tests validating the change
• Documentation has been updated to reflect this change
• The new commits follow conventions explained in CONTRIBUTING.md

[pleerock]

Thank you for contribution!

Can you please add a test, so we can be sure added functionality won't break next time?

Where the number 9 comes from? Is it a postgres default? If yes, can it be added to the PostgresDriver.dataTypeDefaults property?

Or, since it's an optional argument, maybe for simplicity purpose we can simply append column.precision only if it was defined in there?

[alexile]

@pleerock correct, the number comes from ST_AsGeoJSON docs.

Or, since it's an optional argument, maybe for simplicity purpose we can simply append column.precision only if it was defined in there?

Makes sense, I will take a look

[pleerock]

I added a simplification I was asking about. If you'll find time to write tests for this feature, it would be great to have them to avoid future breaking. Thank you!