According to the docs, the CREATE USER syntax on HSQLDB is:
CREATE USER <user name> PASSWORD <password> [ ADMIN ]
The statement provides no way to check if the user exists (à la CREATE USER IF NOT EXISTS), and will fail if a user <user name> already exists.
Digging a little deeper, I found that existing users can be enumerated with
SELECT USER_NAME FROM INFORMATION_SCHEMA.SYSTEM_USERS;
How can I add this check to a one-liner (i.e. one I can run e.g. via DatabaseManager)?
While most CREATE statements support IF NOT EXISTS, there is no way to do this for CREATE USER.
Related
Hello I have such users in my db
I want to delete user postgres so I
DROP USER postgres;
I get the error
ERROR: current user cannot be dropped
After this I try to switch on another user:
postgres=# \connect postgres andrey
and I get the error
FATAL: Peer authentication failed for user "andrey"
The first error message is self-explanatory.
To connect as andrey, you'll have to edit pg_hba.conf and add a line like the following at the very top:
local postgres andrey trust
Then reload the configuration with
SELECT pg_reload_conf();
and you will be able to login as user andrey.
But it is impossible to drop the “bootstrap superuser” postgres. I don't see why that is necessary though. You need a superuser, and if you don't like the name postgres for some reason, you can rename it.
But my advice is to leave user postgres with that name – it is customary to name the bootstrap superuser postgres.
When I create a USER with "CREATE USER user1 WITH PASSWORD 'aaaaaaaa'
It is also creating a ROLE in PG_ROLES table with role name as same as 'user1'
Is it a trigger peforrming the this? Or is it default behavior?
Assuming you are not running a very old (<8.1) version of Postgresql this is explained by the documentation for CREATE USER:
CREATE USER is now an alias for CREATE ROLE. The only difference is
that when the command is spelled CREATE USER, LOGIN is assumed by
default, whereas NOLOGIN is assumed when the command is spelled CREATE
ROLE.
Further details are available in the Database Roles section of the documentation:
The concept of roles subsumes the concepts of “users” and “groups”. In
PostgreSQL versions before 8.1, users and groups were distinct kinds
of entities, but now there are only roles. Any role can act as a user,
a group, or both.
The system catalogs docs explain that:
The view pg_roles provides access to information about database roles.
So based upon this it is to be expected that running CREATE USER will have an impact on pg_roles.
i want to create a user in oracle 12c but i have a problem.after i enter my user name and psw, this warning displatyed: ORA-65096: invalid common user or role name
If you see this error then first you need to alter the session for oracle 12c:
alter session set "_ORACLE_SCRIPT"=true;
after running above command you can create the user. it will work for sure.
CREATE USER your_username IDENTIFIED BY your_password;
Connect first to your pluggableDB
CONN system/systempassword#//localhost:1521/pluggabledatabase
Than you can create your user:
create user marcopolo identified by marco9274;
Note:
You must have created the database as a container database. While, you are trying to create user in the container, i.e. CDB$ROOT, however, you should create the user in the PLUGGABLE database.
You are not supposed to create objects in the container, the container holds the metadata for the pluggable databases. You should use the pluggable database for you general database operations. Else, do not create it as container, and not use multi-tenancy.
See (error: ORA-65096: invalid common user or role name in oracle)
connect system/manager as sysdba
alter session set "_ORACLE_SCRIPT"=true;
create user your_user_name identified by your_password;
grant dba to your_user_name;
I'm new to Postgres' RLS feature. I believe I'm following the documentation appropriately, but am getting unexpected behavior. Consider the following case:
i have a table named report_files
this table has a simple policy, policy <name> for all using (true)
the user has grant all permissions on the table (grant all on all tables in schema testing to testuser;, along with grant execute on all functions ... and grant usage for the schema as well)
the user can now read all fields in the table, but cannot insert records, against expectation
Here's a really short snippet from psql demonstrating the aforementioned: https://gist.github.com/cdaringe/85dd9a7b1278afe4770869dc494216f3
I have set a permissive policy, which clearly evaluates OK as evidenced by the successful select command.
What can I troubleshoot to get the insert to work?
Thanks!
ERROR: permission denied for sequence report_files_id_seq
It looks to me like you need to grant your user permission to use the id sequence: report_files_id_seq
You should be able to do this with the following
GRANT USAGE, SELECT ON SEQUENCE report_files_id_seq TO testuser;
Or to bulk add all tables:
GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA <insert schema name here>
ALL is equivalent to USAGE, SELECT, UPDATE
As I cannot comment yet, I will add some input as an answer if anyone arrives on this thread like me today.
Yes, you have to grant permissions on sequence(s) separately, in addition to the privileges already granted on the table(s). In fact it is what you have to do.
Even if your table is dependant on the sequence object, they are both different objects from the RDBMS point of view, so they require distinct privileges.
As for your indices example, index in a sub-object of a table, and no additional privilege is required to be able to make use of indices so no further action than the index creation is needed.
Moreover, be careful to prefix the sequence name in case it is stored in a schema which is not the default one (public) and which is not in your search_path.
If that is not the case, you may encounter a permission denied error even though you have all necessary privilege on the sequence you aim to work with.
I have created a new user in a MaxDb database. I assign a role that has access to all the tables in roleprivileges but the user can not see these tables.
The user can access the tables if I assign permissions directly to the tables in tableprivileges.
The role has access, other users have this role assigned and they see all the tables.
What can be failing?
Today I've heard of MaxDB for the first time (what an ignoramus, eh?). I'm not sure why you tagged your question with the "Oracle" tag; Google says that MaxDB <> Oracle.
Anyway: it sounds like common problems in Oracle's PL/SQL, where privileges - acquired via roles - won't work, but have to be granted directly to the user.
Saying that "other users have this role assigned and they see all the tables", are you sure that they don't have direct privileges granted as well?
Assuming this deals indeed with MaxDB, and not with Oracle:
In contrast to privileges, roles need to be activated for a user session. Assigning is not enough. It is done by command SET ROLE <role>.
A role may also be activated as default for every new session, with command:
ALTER USER <user> DEFAULT ROLE <role>.
You can also activate all roles assigned to the user, like this:
ALTER USER <user> DEFAULT ROLE ALL.