Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

importccl: disable import with user defined schemas #52729

Merged
merged 1 commit into from
Aug 13, 2020

Conversation

rohany
Copy link
Contributor

@rohany rohany commented Aug 12, 2020

Release note (enterprise change): Cannot use IMPORT to create tables
in user defined schemas. Users should instead create the table with
CREATE TABLE and then use IMPORT INTO.

@rohany rohany requested review from dt and a team August 12, 2020 20:29
@cockroach-teamcity
Copy link
Member

This change is Reviewable

Copy link
Member

@dt dt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

I might word the release note "Cannot use IMPORT to create tables in user-defined schemas; Users should ..." to emphasize the creation aspect (also what is "default" IMPORT? to a user who doesn't know it came before INTO, it might not be clear)

// Due to how we generate and rewrite descriptor ID's for import, we run
// into problems when using user defined schemas.
if parentSchemaID != keys.PublicSchemaID {
return errors.Newf("cannot use IMPORT with a user defined schema; user IMPORT INTO instead")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: s/user/use/ or, better yet create table with CREATE TABLE and then IMPORT INTO it instead

Release note (enterprise change): Cannot use `IMPORT` to create tables
in user defined schemas. Users should instead create the table with
`CREATE TABLE` and then use `IMPORT INTO`.
@rohany
Copy link
Contributor Author

rohany commented Aug 13, 2020

Updated the release note and error message

bors r+

@craig
Copy link
Contributor

craig bot commented Aug 13, 2020

Build succeeded:

@craig craig bot merged commit 8f7481e into cockroachdb:master Aug 13, 2020
jbowens added a commit to jbowens/pebble that referenced this pull request Sep 29, 2020
A database that was created using RocksDB or a previous version of
Pebble does not guarantee that its closed WALs were closed cleanly.
Detect these cases by the absence of a special private
'strict_wal_tail' option. If this special option is missing from the
OPTIONS file, interpret WALs permissively as they're interpreted in the
RocksDB and Pebble versions that wrote them.

See cockroachdb/cockroach#52729.
jbowens added a commit to jbowens/pebble that referenced this pull request Sep 30, 2020
A database that was created using RocksDB or a previous version of
Pebble does not guarantee that its closed WALs were closed cleanly.
Detect these cases by the absence of a special private
'strict_wal_tail' option. If this special option is missing from the
OPTIONS file, interpret WALs permissively as they're interpreted in the
RocksDB and Pebble versions that wrote them.

See cockroachdb/cockroach#52729.
jbowens added a commit to cockroachdb/pebble that referenced this pull request Sep 30, 2020
A database that was created using RocksDB or a previous version of
Pebble does not guarantee that its closed WALs were closed cleanly.
Detect these cases by the absence of a special private
'strict_wal_tail' option. If this special option is missing from the
OPTIONS file, interpret WALs permissively as they're interpreted in the
RocksDB and Pebble versions that wrote them.

See cockroachdb/cockroach#52729.
jbowens added a commit to jbowens/pebble that referenced this pull request Sep 30, 2020
A database that was created using RocksDB or a previous version of
Pebble does not guarantee that its closed WALs were closed cleanly.
Detect these cases by the absence of a special private
'strict_wal_tail' option. If this special option is missing from the
OPTIONS file, interpret WALs permissively as they're interpreted in the
RocksDB and Pebble versions that wrote them.

See cockroachdb/cockroach#52729.
jbowens added a commit to cockroachdb/pebble that referenced this pull request Sep 30, 2020
A database that was created using RocksDB or a previous version of
Pebble does not guarantee that its closed WALs were closed cleanly.
Detect these cases by the absence of a special private
'strict_wal_tail' option. If this special option is missing from the
OPTIONS file, interpret WALs permissively as they're interpreted in the
RocksDB and Pebble versions that wrote them.

See cockroachdb/cockroach#52729.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants