sql: fix qualified index name resolution#24778
Merged
craig[bot] merged 1 commit intocockroachdb:masterfrom Apr 16, 2018
Merged
Conversation
Member
Contributor
Author
|
This will need a cherry-pick. |
Contributor
Author
|
@nvanbenschoten could you try, or help me try, TypeORM with this fix in? To see if it improves the situation. |
7a84d87 to
14d91fb
Compare
justinj
approved these changes
Apr 15, 2018
pkg/sql/resolver.go
Outdated
| // false, otherwise err would be non-nil. | ||
| return nil, nil, nil | ||
| } else if foundTn != nil { | ||
| // Memoize the table name that was found. |
Contributor
There was a problem hiding this comment.
Is this comment still true? Doesn't look like we're sticking anything onto the struct anymore, unless tn points into the struct as a result of having been returned from Normalize, which I think would merit a comment.
Contributor
Author
There was a problem hiding this comment.
Yes it is still true. I added a comment.
314395f to
f9595d6
Compare
In CockroachDB index names are relative to a table name (e.g. `tbl@idx`) but in Postgres index names live in the schema namespace. To offer compatibility with Postgres, CockroachDB implements a special name resolution algorithm for index names specified without the '@' syntax. For example, `DROP INDEX foo` will search all tables in the current schema to find one with index name `foo`. Prior to this patch, CockroachDB was not able to search for a _qualified_ index name specified without the '@' syntax. For example, TypeORM issues `DROP INDEX public."primary"`, expecting to be able to drop the primary index of some table in the `public` schema. This was not recognized by CockroachDB. This patch extends the name resolution for index names to support both partial and complete qualification, using the same name resolution rules as other objects. Release note (sql change): CockroachDB now supports more ways to specify an index name for statements that require one (e.g., `DROP INDEX`, `ALTER INDEX ... RENAME`, etc.), in a way more compatible with PostgreSQL.
f9595d6 to
37def3f
Compare
Contributor
Author
|
bors r+ |
craig bot
pushed a commit
that referenced
this pull request
Apr 16, 2018
24778: sql: fix qualified index name resolution r=knz a=knz Fixes #24475. cc @nvanbenschoten In CockroachDB index names are relative to a table name (e.g. `tbl@idx`) but in Postgres index names live in the schema namespace. To offer compatibility with Postgres, CockroachDB implements a special name resolution algorithm for index names specified without the '@' syntax. For example, `DROP INDEX foo` will search all tables in the current schema to find one with index name `foo`. Prior to this patch, CockroachDB was not able to search for a _qualified_ index name specified without the '@' syntax. For example, TypeORM issues `DROP INDEX public."primary"`, expecting to be able to drop the primary index of some table in the `public` schema. This was not recognized by CockroachDB. This patch extends the name resolution for index names to support both partial and complete qualification, using the same name resolution rules as other objects. Release note (sql change): CockroachDB now supports more ways to specify an index name for statements that require one (e.g., `DROP INDEX`, `ALTER INDEX ... RENAME`, etc.), in a way more compatible with PostgreSQL. Co-authored-by: Raphael 'kena' Poss <knz@cockroachlabs.com>
Contributor
Build succeeded |
Contributor
|
@knz yeah, this seems to have fixed the issue with TypeORM. Thanks! |
craig bot
pushed a commit
that referenced
this pull request
Apr 16, 2018
24817: cherrypick-2.0: sql: fix qualified index name resolution r=knz a=knz Picks #24778. cc @cockroachdb/release 24842: cherry-pick 2.0: sql: use a reusable name resolution algo for star expansions r=knz a=knz Picks #24811. cc @cockroachdb/release Co-authored-by: Raphael 'kena' Poss <knz@cockroachlabs.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #24475.
cc @nvanbenschoten
In CockroachDB index names are relative to a table name
(e.g.
tbl@idx) but in Postgres index names live in the schemanamespace. To offer compatibility with Postgres, CockroachDB
implements a special name resolution algorithm for index names
specified without the '@' syntax. For example,
DROP INDEX foowillsearch all tables in the current schema to find one with index name
foo.Prior to this patch, CockroachDB was not able to search for a
qualified index name specified without the '@' syntax. For example,
TypeORM issues
DROP INDEX public."primary", expecting to be able todrop the primary index of some table in the
publicschema. This wasnot recognized by CockroachDB.
This patch extends the name resolution for index names to support both
partial and complete qualification, using the same name resolution
rules as other objects.
Release note (sql change): CockroachDB now supports more ways to
specify an index name for statements that require one (e.g.,
DROP INDEX,ALTER INDEX ... RENAME, etc.), in a way more compatible withPostgreSQL.