Codestin Search App

samuelmbabhazi · 2026-08-02T14:11:01Z

Description of change

When loading tables, the Postgres driver reads srid and type from the PostGIS geometry_columns view but ignores coord_dimension. PostGIS folds the Z dimension into coord_dimension and only keeps the M suffix in type, so a geometry(PointZ) column comes back as feature type POINT. The loaded table then never matches metadata declaring PointZ, and migration:generate produces the same ALTER over and over.

Verified against PostGIS 3.6, where the views report:

declared column	view	`coord_dimension`	`type`
`geometry(Geometry)`	geometry_columns	2	`GEOMETRY`
`geometry(GeometryZ)`	geometry_columns	3	`GEOMETRY`
`geometry(GeometryM)`	geometry_columns	3	`GEOMETRYM`
`geometry(GeometryZM)`	geometry_columns	4	`GEOMETRY`
`geography(PointZ)`	geography_columns	3	`PointZ`

The query now also selects coord_dimension, and the loader appends the Z or ZM suffix when the dimension calls for it and the suffix is not already present. The guard keeps geography_columns working unchanged, since that view already reports the full suffix in type.

SpatialColumnOptions.spatialFeatureType previously only accepted the plain GeoJSON type names, so a dimensional column could not even be declared without a cast. The type now also accepts the Z, M and ZM suffixed forms, and the decorator reference documentation mentions them.

The regression test declares geometry PointZ, PointM and PointZM columns plus a geography PointZ column, then asserts both that the loaded table reports the dimensional feature types and that the schema builder reports no pending changes, which is the loop from the issue. Reverting the source changes makes both tests fail. The full spatial test suite passes against the postgres-14 PostGIS image from docker-compose.

CockroachDB

As requested in review, the same change is applied to the CockroachDB driver, with the same block shape so the two can be extracted together later. Probed on CockroachDB v25.2, the views match PostGIS except for one case:

declared column	view	`coord_dimension`	PostGIS `type`	CockroachDB `type`
`geometry(PointZ)`	geometry_columns	3	`POINT`	`POINT`
`geometry(PointM)`	geometry_columns	3	`POINTM`	`POINT`
`geometry(PointZM)`	geometry_columns	4	`POINT`	`POINT`
`geometry(GeometryZM)`	geometry_columns	4	`GEOMETRY`	`GEOMETRY`
`geography(PointZ)`	geography_columns	3	`PointZ`	`PointZ`
`geography(PointZM)`	geography_columns	4	`PointZM`	`PointZM`

CockroachDB drops the M suffix from geometry_columns, which makes PointM indistinguishable from PointZ there. The driver already loads crdb_sql_type for every column (GEOMETRY(POINTM,4326)), so the declared feature type is taken from it when present and the coord_dimension logic stays as the shared fallback. The only other difference is that coord_dimension comes back as a bigint string, parsed the same way the existing code parses srid.

The CockroachDB spatial suite gains the same two tests (dimensional feature types loaded, no pending schema changes), and reverting the driver change makes exactly those two fail. Both spatial suites pass: 26 tests across postgres, cockroachdb and mysql.

Pull-Request Checklist

Code is up-to-date with the master branch
This pull request links a relevant issue using a closing keyword:
Fixes #NNNN, Closes #NNNN, or Resolves #NNNN
There are new or updated tests validating the change (tests/**.test.ts)
Documentation has been updated to reflect this change (docs/docs/**.md)

qodo-free-for-open-source-projects · 2026-08-02T14:14:53Z

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (1) 📜 Skill insights (0)

1. Test added under test/github-issues 📘 Rule violation ⚙ Maintainability

Description

The fix for #12747 is validated only via a new test under test/github-issues/12747, rather than
being placed in the functional test suite. This reduces long-term maintainability and violates the
project preference for functional tests for issue fixes.

Code

test/github-issues/12747/issue-12747.test.ts[R11-12]

+describe("github issues > #12747 postgres driver ignores coord_dimension when loading geometry columns", () => {
+    let dataSources: DataSource[]

Evidence

PR Compliance ID 3 requires issue fixes to add/update tests in the functional suite rather than only
adding tests under test/github-issues. The PR introduces a new regression test located under
test/github-issues/12747/, indicating the issue fix is covered only in the per-issue test area.

Rule 3: Prefer functional tests over per-issue tests
test/github-issues/12747/issue-12747.test.ts[11-12]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The regression coverage for #12747 was added under `test/github-issues/12747`, but compliance requires issue fixes to live in the functional test suite when possible.
## Issue Context
A new test file was introduced at `test/github-issues/12747/issue-12747.test.ts` to cover Postgres spatial `coord_dimension` handling. There does not appear to be a corresponding functional test addition for #12747.
## Fix Focus Areas
- test/github-issues/12747/issue-12747.test.ts[1-55]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. Geometry* type not allowed 🐞 Bug ≡ Correctness

Description

SpatialColumnOptions.spatialFeatureType is derived from GeoJSON Geometry["type"], which does not
include the generic PostGIS subtype "Geometry", so values like "Geometry"/"GeometryZM"
mentioned in the docs/comments will fail TypeScript checking. This is a user-facing
API/type-definition inconsistency introduced by the updated option typing and documentation example.

Code

src/decorator/options/SpatialColumnOptions.ts[R12-13]
+    spatialFeatureType?:
+        Geometry["type"] | `${Geometry["type"]}${"Z" | "M" | "ZM"}`

Evidence
The docs and SpatialColumnOptions comment explicitly mention Geometry/GeometryZM as valid
inputs, but the underlying GeoJSON Geometry union only contains concrete GeoJSON literals (e.g.
Point, Polygon, GeometryCollection) and therefore cannot produce Geometry* strings.
docs/docs/help/3-decorator-reference.md[168-168]
src/decorator/options/SpatialColumnOptions.ts[8-13]
src/driver/types/GeoJsonTypes.ts[80-88]
src/decorator/columns/Column.ts[57-60]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`SpatialColumnOptions.spatialFeatureType` is typed as `Geometry["type"] | `${Geometry["type"]}${...}``, but `Geometry["type"]` is a GeoJSON union that excludes the generic `"Geometry"` subtype used by PostGIS and referenced in the docs/examples (e.g. `GeometryZM`). This makes valid/documented declarations fail type-checking.
### Issue Context
The `@Column(type: SpatialColumnType, options?: ColumnCommonOptions & SpatialColumnOptions)` overload uses `SpatialColumnOptions`, so this typing directly affects TS users of `@Column("geometry"|"geography", { spatialFeatureType: ... })`.
### Fix Focus Areas
- src/decorator/options/SpatialColumnOptions.ts[6-14]
### Suggested fix
Define a PostGIS feature-type base union that includes the GeoJSON literals plus `"Geometry"`, and apply suffixes to that base, e.g.:

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. ZM suffix duplication edge-case 🐞 Bug ≡ Correctness

Description

When coord_dimension === 4, the loader appends "ZM" unless the type already ends with "ZM",
which can produce invalid strings like "POINTMZM" if introspection returns a 4D type that already
ends with "M". If this occurs, introspected schema won’t match metadata and can re-trigger
repetitive migration diffs for ZM columns.

Code

src/driver/postgres/PostgresQueryRunner.ts[R3981-3984]

+                                        results[0].coord_dimension === 4 &&
+                                        !upperType.endsWith("ZM")
+                                    ) {
+                                        spatialFeatureType += "ZM"

Evidence

The new logic appends ZM whenever coord_dimension===4 and the existing type doesn’t end with
ZM; it doesn’t account for a pre-existing trailing M suffix, despite the comment noting
geometry_columns may keep an M suffix in type.

src/driver/postgres/PostgresQueryRunner.ts[3965-3988]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `coord_dimension === 4` branch appends `ZM` based only on `!upperType.endsWith("ZM")`. If `results[0].type` already carries an `M` suffix (e.g. `POINTM`) while also being 4D, the code will generate `POINTMZM` rather than normalizing to `POINTZM`.
### Issue Context
The surrounding comment indicates `geometry_columns` may keep an `M` suffix in `type` while using `coord_dimension` for Z, so the code should safely normalize all suffix combinations.
### Fix Focus Areas
- src/driver/postgres/PostgresQueryRunner.ts[3965-3988]
### Suggested fix
Normalize based on `coord_dimension` and current suffix, for example:
- Compute `dim = Number(results[0].coord_dimension)` (to avoid strict-equality surprises).
- For `dim === 3`:
- if endsWith `ZM` -> leave (or potentially downgrade, but likely not needed)
- else if endsWith `Z` or `M` -> leave
- else append `Z`
- For `dim === 4`:
- if endsWith `ZM` -> leave
- else if endsWith `Z` -> replace trailing `Z` with `ZM`
- else if endsWith `M` -> replace trailing `M` with `ZM`
- else append `ZM`
This avoids producing `*MZM`/`*ZZM` strings while keeping `geography_columns` behavior intact.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Author self-review: I have reviewed the code review findings, and addressed the relevant ones.

Tip of the day

💡 Did you know, you can start a comment with 'qodo' or '@qodo' to chat about any finding

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Previous reviews

Review updated until commit e4593cc ⚖️ Balanced

Results up to commit 30b4525

🐞 Bugs (2) 📘 Rule violations (1) 📜 Skill insights (0)

1. Test added under test/github-issues 📘 Rule violation ⚙ Maintainability

Description

The fix for #12747 is validated only via a new test under test/github-issues/12747, rather than
being placed in the functional test suite. This reduces long-term maintainability and violates the
project preference for functional tests for issue fixes.

Code

test/github-issues/12747/issue-12747.test.ts[R11-12]

+describe("github issues > #12747 postgres driver ignores coord_dimension when loading geometry columns", () => {
+    let dataSources: DataSource[]

Evidence

PR Compliance ID 3 requires issue fixes to add/update tests in the functional suite rather than only
adding tests under test/github-issues. The PR introduces a new regression test located under
test/github-issues/12747/, indicating the issue fix is covered only in the per-issue test area.

Rule 3: Prefer functional tests over per-issue tests
test/github-issues/12747/issue-12747.test.ts[11-12]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The regression coverage for #12747 was added under `test/github-issues/12747`, but compliance requires issue fixes to live in the functional test suite when possible.
## Issue Context
A new test file was introduced at `test/github-issues/12747/issue-12747.test.ts` to cover Postgres spatial `coord_dimension` handling. There does not appear to be a corresponding functional test addition for #12747.
## Fix Focus Areas
- test/github-issues/12747/issue-12747.test.ts[1-55]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. Geometry* type not allowed 🐞 Bug ≡ Correctness

Description

SpatialColumnOptions.spatialFeatureType is derived from GeoJSON Geometry["type"], which does not
include the generic PostGIS subtype "Geometry", so values like "Geometry"/"GeometryZM"
mentioned in the docs/comments will fail TypeScript checking. This is a user-facing
API/type-definition inconsistency introduced by the updated option typing and documentation example.

Code

src/decorator/options/SpatialColumnOptions.ts[R12-13]
+    spatialFeatureType?:
+        Geometry["type"] | `${Geometry["type"]}${"Z" | "M" | "ZM"}`

Evidence
The docs and SpatialColumnOptions comment explicitly mention Geometry/GeometryZM as valid
inputs, but the underlying GeoJSON Geometry union only contains concrete GeoJSON literals (e.g.
Point, Polygon, GeometryCollection) and therefore cannot produce Geometry* strings.
docs/docs/help/3-decorator-reference.md[168-168]
src/decorator/options/SpatialColumnOptions.ts[8-13]
src/driver/types/GeoJsonTypes.ts[80-88]
src/decorator/columns/Column.ts[57-60]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`SpatialColumnOptions.spatialFeatureType` is typed as `Geometry["type"] | `${Geometry["type"]}${...}``, but `Geometry["type"]` is a GeoJSON union that excludes the generic `"Geometry"` subtype used by PostGIS and referenced in the docs/examples (e.g. `GeometryZM`). This makes valid/documented declarations fail type-checking.
### Issue Context
The `@Column(type: SpatialColumnType, options?: ColumnCommonOptions & SpatialColumnOptions)` overload uses `SpatialColumnOptions`, so this typing directly affects TS users of `@Column("geometry"|"geography", { spatialFeatureType: ... })`.
### Fix Focus Areas
- src/decorator/options/SpatialColumnOptions.ts[6-14]
### Suggested fix
Define a PostGIS feature-type base union that includes the GeoJSON literals plus `"Geometry"`, and apply suffixes to that base, e.g.:

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. ZM suffix duplication edge-case 🐞 Bug ≡ Correctness

Description

When coord_dimension === 4, the loader appends "ZM" unless the type already ends with "ZM",
which can produce invalid strings like "POINTMZM" if introspection returns a 4D type that already
ends with "M". If this occurs, introspected schema won’t match metadata and can re-trigger
repetitive migration diffs for ZM columns.

Code

src/driver/postgres/PostgresQueryRunner.ts[R3981-3984]

+                                        results[0].coord_dimension === 4 &&
+                                        !upperType.endsWith("ZM")
+                                    ) {
+                                        spatialFeatureType += "ZM"

Evidence

The new logic appends ZM whenever coord_dimension===4 and the existing type doesn’t end with
ZM; it doesn’t account for a pre-existing trailing M suffix, despite the comment noting
geometry_columns may keep an M suffix in type.

src/driver/postgres/PostgresQueryRunner.ts[3965-3988]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `coord_dimension === 4` branch appends `ZM` based only on `!upperType.endsWith("ZM")`. If `results[0].type` already carries an `M` suffix (e.g. `POINTM`) while also being 4D, the code will generate `POINTMZM` rather than normalizing to `POINTZM`.
### Issue Context
The surrounding comment indicates `geometry_columns` may keep an `M` suffix in `type` while using `coord_dimension` for Z, so the code should safely normalize all suffix combinations.
### Fix Focus Areas
- src/driver/postgres/PostgresQueryRunner.ts[3965-3988]
### Suggested fix
Normalize based on `coord_dimension` and current suffix, for example:
- Compute `dim = Number(results[0].coord_dimension)` (to avoid strict-equality surprises).
- For `dim === 3`:
- if endsWith `ZM` -> leave (or potentially downgrade, but likely not needed)
- else if endsWith `Z` or `M` -> leave
- else append `Z`
- For `dim === 4`:
- if endsWith `ZM` -> leave
- else if endsWith `Z` -> replace trailing `Z` with `ZM`
- else if endsWith `M` -> replace trailing `M` with `ZM`
- else append `ZM`
This avoids producing `*MZM`/`*ZZM` strings while keeping `geography_columns` behavior intact.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Results up to commit a56bbd0

🐞 Bugs (2) 📘 Rule violations (1) 📜 Skill insights (0)

1. Test added under test/github-issues 📘 Rule violation ⚙ Maintainability

Description

The fix for #12747 is validated only via a new test under test/github-issues/12747, rather than
being placed in the functional test suite. This reduces long-term maintainability and violates the
project preference for functional tests for issue fixes.

Code

test/github-issues/12747/issue-12747.test.ts[R11-12]

+describe("github issues > #12747 postgres driver ignores coord_dimension when loading geometry columns", () => {
+    let dataSources: DataSource[]

Evidence

PR Compliance ID 3 requires issue fixes to add/update tests in the functional suite rather than only
adding tests under test/github-issues. The PR introduces a new regression test located under
test/github-issues/12747/, indicating the issue fix is covered only in the per-issue test area.

Rule 3: Prefer functional tests over per-issue tests
test/github-issues/12747/issue-12747.test.ts[11-12]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The regression coverage for #12747 was added under `test/github-issues/12747`, but compliance requires issue fixes to live in the functional test suite when possible.

## Issue Context
A new test file was introduced at `test/github-issues/12747/issue-12747.test.ts` to cover Postgres spatial `coord_dimension` handling. There does not appear to be a corresponding functional test addition for #12747.

## Fix Focus Areas
- test/github-issues/12747/issue-12747.test.ts[1-55]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. Geometry* type not allowed 🐞 Bug ≡ Correctness

Description

SpatialColumnOptions.spatialFeatureType is derived from GeoJSON Geometry["type"], which does not
include the generic PostGIS subtype "Geometry", so values like "Geometry"/"GeometryZM"
mentioned in the docs/comments will fail TypeScript checking. This is a user-facing
API/type-definition inconsistency introduced by the updated option typing and documentation example.

Code

src/decorator/options/SpatialColumnOptions.ts[R12-13]
+    spatialFeatureType?:
+        Geometry["type"] | `${Geometry["type"]}${"Z" | "M" | "ZM"}`

Evidence
The docs and SpatialColumnOptions comment explicitly mention Geometry/GeometryZM as valid
inputs, but the underlying GeoJSON Geometry union only contains concrete GeoJSON literals (e.g.
Point, Polygon, GeometryCollection) and therefore cannot produce Geometry* strings.
docs/docs/help/3-decorator-reference.md[168-168]
src/decorator/options/SpatialColumnOptions.ts[8-13]
src/driver/types/GeoJsonTypes.ts[80-88]
src/decorator/columns/Column.ts[57-60]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`SpatialColumnOptions.spatialFeatureType` is typed as `Geometry["type"] | `${Geometry["type"]}${...}``, but `Geometry["type"]` is a GeoJSON union that excludes the generic `"Geometry"` subtype used by PostGIS and referenced in the docs/examples (e.g. `GeometryZM`). This makes valid/documented declarations fail type-checking.

### Issue Context
The `@Column(type: SpatialColumnType, options?: ColumnCommonOptions & SpatialColumnOptions)` overload uses `SpatialColumnOptions`, so this typing directly affects TS users of `@Column("geometry"|"geography", { spatialFeatureType: ... })`.

### Fix Focus Areas
- src/decorator/options/SpatialColumnOptions.ts[6-14]

### Suggested fix
Define a PostGIS feature-type base union that includes the GeoJSON literals plus `"Geometry"`, and apply suffixes to that base, e.g.:

```ts
type SpatialFeatureTypeBase = Geometry["type"] | "Geometry"
spatialFeatureType?:
 | SpatialFeatureTypeBase
 | `${SpatialFeatureTypeBase}${"Z" | "M" | "ZM"}`
```

(Optionally add/adjust type-level tests if the repo has a pattern for that.)

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. ZM suffix duplication edge-case 🐞 Bug ≡ Correctness

Description

When coord_dimension === 4, the loader appends "ZM" unless the type already ends with "ZM",
which can produce invalid strings like "POINTMZM" if introspection returns a 4D type that already
ends with "M". If this occurs, introspected schema won’t match metadata and can re-trigger
repetitive migration diffs for ZM columns.

Code

src/driver/postgres/PostgresQueryRunner.ts[R3981-3984]

+                                        results[0].coord_dimension === 4 &&
+                                        !upperType.endsWith("ZM")
+                                    ) {
+                                        spatialFeatureType += "ZM"

Evidence

The new logic appends ZM whenever coord_dimension===4 and the existing type doesn’t end with
ZM; it doesn’t account for a pre-existing trailing M suffix, despite the comment noting
geometry_columns may keep an M suffix in type.

src/driver/postgres/PostgresQueryRunner.ts[3965-3988]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The `coord_dimension === 4` branch appends `ZM` based only on `!upperType.endsWith("ZM")`. If `results[0].type` already carries an `M` suffix (e.g. `POINTM`) while also being 4D, the code will generate `POINTMZM` rather than normalizing to `POINTZM`.

### Issue Context
The surrounding comment indicates `geometry_columns` may keep an `M` suffix in `type` while using `coord_dimension` for Z, so the code should safely normalize all suffix combinations.

### Fix Focus Areas
- src/driver/postgres/PostgresQueryRunner.ts[3965-3988]

### Suggested fix
Normalize based on `coord_dimension` and current suffix, for example:
- Compute `dim = Number(results[0].coord_dimension)` (to avoid strict-equality surprises).
- For `dim === 3`:
 - if endsWith `ZM` -> leave (or potentially downgrade, but likely not needed)
 - else if endsWith `Z` or `M` -> leave
 - else append `Z`
- For `dim === 4`:
 - if endsWith `ZM` -> leave
 - else if endsWith `Z` -> replace trailing `Z` with `ZM`
 - else if endsWith `M` -> replace trailing `M` with `ZM`
 - else append `ZM`

This avoids producing `*MZM`/`*ZZM` strings while keeping `geography_columns` behavior intact.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

alumni · 2026-08-26T15:44:16Z

                                    `SELECT * FROM (` +
                                    `SELECT "f_table_schema" "table_schema", "f_table_name" "table_name", ` +
-                                    `"f_${tableColumn.type}_column" "column_name", "srid", "type" ` +
+                                    `"f_${tableColumn.type}_column" "column_name", "srid", "type", "coord_dimension" ` +


Could we extend this to CockroachDB? It should be more-or-less compatible with PostGIS, they also support Z/M dimensions: https://docs.cockroachlabs.com/docs/stable/point

Over time, we'd like to extract the common code (like Sqlite), so it's good to have as little variance as possible.

Done in e4593cc. CockroachDB exposes the same views, so the block is the same shape as the Postgres one, with two differences I could not avoid after probing v25.2 (table in the PR description): coord_dimension comes back as a bigint string, parsed like the existing srid, and CockroachDB drops the M suffix from geometry_columns, which makes PointM indistinguishable from PointZ there. Since the driver already loads crdb_sql_type for every column, the declared feature type is taken from it when present and the coord_dimension logic stays as the shared fallback. The CockroachDB spatial suite gains the same two tests, and both spatial suites pass.

pkg-pr-new · 2026-08-26T16:00:29Z

typeorm-sql-js-example
```
npm i https://pkg.pr.new/typeorm@12749
```

commit: e4593cc

Closes typeorm#12747

CockroachDB exposes the same geometry_columns and geography_columns views as PostGIS, so the dimensional suffix is restored the same way. Two differences are handled: coord_dimension comes back as a bigint string, and geometry_columns drops the M suffix from the type, which makes PointM look like PointZ, so the declared type in crdb_sql_type takes precedence when it carries a feature type.

gioboa

Thanks @samuelmbabhazi 👏

github-actions Bot added the linked-issue PR references an issue label Aug 2, 2026

qodo-free-for-open-source-projects Bot added the Compliance violation label Aug 2, 2026

samuelmbabhazi force-pushed the fix/postgres-geometry-coord-dimension branch from a56bbd0 to 30b4525 Compare August 2, 2026 14:32

qodo-free-for-open-source-projects Bot removed the Compliance violation label Aug 2, 2026

alumni reviewed Aug 26, 2026

View reviewed changes

samuelmbabhazi added 2 commits August 26, 2026 18:16

fix(postgres): read coord_dimension when loading spatial columns

d1e3d9e

Closes typeorm#12747

samuelmbabhazi force-pushed the fix/postgres-geometry-coord-dimension branch from 30b4525 to e4593cc Compare August 26, 2026 16:17

samuelmbabhazi changed the title ~~fix(postgres): read coord_dimension when loading spatial columns~~ fix(postgres,cockroachdb): read coord_dimension when loading spatial columns Aug 26, 2026

samuelmbabhazi requested a review from alumni August 26, 2026 16:24

alumni approved these changes Aug 26, 2026

View reviewed changes

alumni changed the title ~~fix(postgres,cockroachdb): read coord_dimension when loading spatial columns~~ fix(postgres): read coord_dimension when loading spatial columns Aug 26, 2026

gioboa approved these changes Aug 26, 2026

View reviewed changes

alumni merged commit 1b2df90 into typeorm:master Aug 27, 2026
51 checks passed

github-actions Bot added this to the 2.0.next milestone Aug 27, 2026

mohanagy mentioned this pull request Sep 2, 2026

[P0 Prototype] Falsify interactive TypeScript evidence navigation against Native exploration mohanagy/madar#736

Closed

Navigation Menu

Uh oh!

Uh oh!

fix(postgres): read `coord_dimension` when loading spatial columns - #12749

fix(postgres): read `coord_dimension` when loading spatial columns#12749
alumni merged 2 commits into
typeorm:masterfrom
samuelmbabhazi:fix/postgres-geometry-coord-dimension

samuelmbabhazi commented Aug 2, 2026 •

edited

Loading

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 2, 2026 •

edited

Loading

Uh oh!

alumni Aug 26, 2026

Uh oh!

samuelmbabhazi Aug 26, 2026

Uh oh!

pkg-pr-new Bot commented Aug 26, 2026 •

edited

Loading

Uh oh!

gioboa left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

Uh oh!

Uh oh!

Conversation

samuelmbabhazi commented Aug 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description of change

CockroachDB

Pull-Request Checklist

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Uh oh!

alumni Aug 26, 2026

Choose a reason for hiding this comment

Uh oh!

samuelmbabhazi Aug 26, 2026

Choose a reason for hiding this comment

Uh oh!

pkg-pr-new Bot commented Aug 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gioboa left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

samuelmbabhazi commented Aug 2, 2026 •

edited

Loading

qodo-free-for-open-source-projects Bot commented Aug 2, 2026 •

edited

Loading

pkg-pr-new Bot commented Aug 26, 2026 •

edited

Loading