Fix relational JDBC location-overlap index to match the optimized sibling-check query

[iprithv]

The optimized sibling check (OPTIMIZED_SIBLING_CHECK) reads location_without_scheme through QueryGenerator.generateOverlapQuery, whose predicate is WHERE realm_id = ? AND catalog_id = ? AND (...).

On Postgres and CockroachDB, idx_locations currently leads with parent_id instead of catalog_id:

-- before (postgres/cockroachdb)
ON entities USING btree (realm_id, parent_id, location_without_scheme)

Because of that, the query can only use the realm_id prefix and ends up doing a realm/catalog-wide scan instead of the intended indexed lookup. H2 already uses (realm_id, catalog_id, location_without_scheme), which is why the default H2-based test matrix didn't catch this.

This changes the latest (v5) Postgres and CockroachDB scripts to use (realm_id, catalog_id, location_without_scheme) and adds SchemaLocationIndexParityTest to make sure the idx_locations column list stays consistent across backends.

Older scripts (v2-v4) are intentionally left unchanged. Fresh installs always start at the latest schema version, so those scripts are frozen. Existing realms on older versions are covered by the manual DDL in CHANGELOG.md.

The optimized sibling check is meant to replace an O(siblings) listing with an indexed lookup. With the current index on Postgres and CockroachDB, table/namespace creation can instead scale with the total catalog size.

Polaris doesn't have automated schema migrations, so existing Postgres/CockroachDB deployments will need to recreate the index manually:

DROP INDEX polaris_schema.idx_locations;
CREATE INDEX idx_locations ON polaris_schema.entities USING btree (realm_id, catalog_id, location_without_scheme)
  WHERE location_without_scheme IS NOT NULL;

H2 is unaffected.

[vigneshio]

LGTM..

[zhang-arvin]

I would like to work on this issue.

[vigneshio]

I would like to work on this issue.

Thanks @zhang-arvin - This is already being handled here. Please close #5331 so we keep the discussion in one place.

[adutra]

That's an interesting issue. I'm not sure we need to keep the scripts in lockstep.

[adutra]

Let's actually keep them in sync. This will make the migration to single DDL scripts easier imho. See #5349.

[adutra]

@iprithv could you please fix the merge conflicts? 🙏

[iprithv]

@adutra sure, done. thanks!