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

User can not insert records into table with column "generated by default as identity" in its DDL [CORE4161] #4488

Closed
firebird-automations opened this issue Aug 4, 2013 · 6 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @pavel-zotov

Votes: 1

isql 192.168.0.201/3330:empty30 -user sysdba -pas masterke
Database: 192.168.0.201/3330:empty30, User: sysdba
SQL> create table autoid_test(id int generated by default as identity primary key, f01 int);
SQL> insert into autoid_test(f01) values(100);
SQL> insert into autoid_test(f01) values(200);
SQL> insert into autoid_test(f01) values(300);
SQL> commit;
SQL> select * from autoid_test; commit;

      ID          F01

============ ============
1 100
2 200
3 300

SQL> show sequ;
There are no generators in this database
SQL> commit;

-- now we create non_priviledged user and give him all possible rights for DML operations:
SQL> create user u30tmp1 password '123'; commit;
SQL> grant insert,update,delete,select on autoid_test to u30tmp1; commit;

-- connect under just created user and check what he really can do with that table:
SQL> connect '192.168.0.201/3330:empty30' user 'u30tmp1' password '123';
Database: '192.168.0.201/3330:empty30', User: u30tmp1
SQL> select * from autoid_test; -- OK

      ID          F01

============ ============
1 100
2 200
3 300

SQL> update autoid_test set f01=-f01 where id=1; -- OK
SQL> delete from autoid_test where id>1; -- OK
SQL> insert into autoid_test(f01) values(555); -- error
Statement failed, SQLSTATE = 28000
no permission for USAGE access to GENERATOR RDB$1

Commits: 0b46869 FirebirdSQL/fbt-repository@b365fb1

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Dmitry Yemanov [ dimitr ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

Funny enough, the SQL spec declares both IDENTITY and USAGE features but I failed to find how they are expected to correlate. Technically speaking, there are two options: grant the implicit generator's USAGE permission to PUBLIC or imply the USAGE permission every time an INSERT (and perhaps later UPDATE as well) permission is granted for a table. But for the latter, the question is whether USAGE should be revoked when INSERT is revoked.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Regression: 3.0 Alpha 1 [ 10331 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 3.0 Beta 2 [ 10586 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Resolved [ 5 ]

QA Status: Done successfully

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Closed [ 6 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants