Issue Details (XML | Word | Printable)

Key: CORE-4161
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Dmitry Yemanov
Reporter: Pavel Zotov
Votes: 1
Watchers: 5

If you were logged in you would be able to see more operations.
Firebird Core

User can not insert records into table with column "generated by default as identity" in its DDL

Created: 04/Aug/13 09:56 AM   Updated: 01/Jun/15 06:23 PM
Component/s: Engine
Affects Version/s: 3.0 Alpha 1
Fix Version/s: 3.0 Beta 2

QA Status: Done successfully

 Description  « Hide
isql -user sysdba -pas masterke
Database:, 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 '' user 'u30tmp1' password '123';
Database: '', 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

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 04/Aug/13 12:23 PM
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.