How to drop a Redshift index? - postgresql

I've got a superuser account and am trying to drop an index on a Redshift table with:
DROP INDEX my_table_pkey;
But I receive a ERROR: Insufficient privileges. I'm confused because I can drop the table just fine, and I'm logged in as a Superuser.
# \du admin
List of roles
Role name | Attributes | Member of
-----------+----------------------+-----------
admin | Superuser, Create DB |
I've even tried
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO admin;
But I still get the insufficient privileges error when I try to drop the index.
Any ideas?

Please note that as documented here, Redshift doesn't support indexes so likely as not, there's not an actual index to drop. Primary and foreign keys are for informational purposes only but are still recommend (see Defining Constraints) for the optimizer. It is up to the application though, to actually enforce the keys.

you can't drop index in Redshift.
but you can.
create your table without the index.
insert the data from the old table
change the table name

Related

Unable to drop user because I cannot revoke default priviliges in Redshift

I am having issues with dropping a user becauase it has default privileges, but I am as well unable to revoke those privileges.
To reproduce my issue:
-- executed with master user redshift_master
CREATE USER anton_test_user PASSWORD '***' IN GROUP redshift_dev;
Then using anton_test_user
CREATE SCHEMA anton_test_schema;
CREATE TABLE anton_test_schema.anton_test_table AS SELECT 1 AS anton;
ALTER DEFAULT PRIVILEGES IN SCHEMA anton_test_schema
GRANT SELECT ON TABLES TO GROUP redshift_readonly;
Again with redshift_master
ALTER SCHEMA anton_test_schema OWNER TO redshift_master;
ALTER TABLE anton_test_schema.anton_test_table OWNER TO redshift_master;
Now trying to drop the user it complains about default privileges:
DROP USER anton_test_user;
Result as expected:
owner of default privileges on new relations belonging to user
anton_test_user in schema anton_test_schema;
Now to the weird part, still with redshift_master
ALTER DEFAULT PRIVILEGES FOR USER anton_test_user IN SCHEMA anton_test_schema
REVOKE ALL ON TABLES FROM redshift_readonly;
Gives Invalid operation: permission denied for schema anton_test_schema. What?
If running with anton_test_user
ALTER DEFAULT PRIVILEGES IN SCHEMA anton_test_schema
REVOKE ALL ON TABLES FROM redshift_readonly;
As well gives Invalid operation: permission denied for schema anton_test_schema.
The only way for me to solve this and being able to drop anton_test_user was to, with redshift_master drop the schema and table completely
DROP TABLE anton_test_schema.anton_test_table;
DROP SCHEMA anton_test_schema;
DROP USER anton_test_user; -- it works now
Transfering ownership back to anton_test_user and then revoking default privileges did not help - dropping the table and schema was the only solution I could find.
My completely uninformed guess is that anton_test_user had lost permissions to the schema, so no grants for the user could be applied or revoked in that schema.
Question(s):
Is there any way to avoid dropping anton_test_schema and anton_test_table while also dropping anton_test_user?
Is it supposed to work this way?
Do Postgres behave in the same way?
This is a bit of a follow up to a question already asked, to which I gave an answer - but I have no idea what is going on even though I came up with a "solution" ("" because dropping objects was a solution, albeit a pretty poor one). It might be that I have completely misunderstood user privileges in Redshift as well.
The original question is not completely the same as this - and I would like to know what is going on, so it is not really a repost even though it might look like it.
I had the same issue myself. I was able to avoid dropping the user/schema by first re-granting access of the schema to my end user (my version of anton_test_user).
grant all on schema analyst_data to anton_test_user;
After doing so, I was able to run my alter default privileges command
ALTER DEFAULT PRIVILEGES for user <user> in schema <schema> REVOKE ALL on tables FROM group <group>;
Your uninformed guess was spot on 😀

Redshift: Truncating Table Created by another user

I'm trying to truncate a table in redshift but it's throwing the following error -
SQL Error [500310] [42501]: Amazon Invalid operation: must
be owner of relation table;
I have already granted all the privileges on the table to the user. As checked through the online documentation for redshift, I can't grant the truncate table access explicitly like the way it's enabled now in PostgreSQL. Is there a way or a best practice to handle this scenario?
As you say only the table owner or a superuser can truncate a table. There are several options.
Change the table to be owned by the user that needs to truncate but this may not meet other constraints
Alter table to current user, truncate, and alter it back to the previous user (requires DROP permission)
Drop and recreate the table but this may break dependencies
Make a table LIKE the original, perform an ALTER TABLE APPEND to this new table, and then drop the new table (some restrictions like no identity columns)

Postgresql role with no drop table permision

Is it possible to set role with access to one database, with all privileges except to drop tables?
Not really. If a user can issue CREATE TABLE, it can issue a DROP for that table as well. From the docs:
The right to drop an object, or to alter its definition in any way, is not treated as a grantable privilege; it is inherent in the owner, and cannot be granted or revoked.
And as noted by the CREATE TABLE docs:
The table will be owned by the user issuing the command.
There is no mechanism to allow a user to create tables that they do not own and therefore cannot drop.

How to check foreign table permissions on Postgres

does anybody know how to check user permissions for a foreign table on Postgres?
I've tried \dE and \det, but no luck.
I just want to know who can select, insert, update and delete from a foreign table.
\dp is a psql meta-command which lists tables with their associated access privileges. I believe \z is doing the same thing. It also lists privileges for accessing views and sequences.

Alter Table Of Other User in Firebird

When I try to alter a table from a different owner in Firebird I got this error:
unsuccessful metadata update
MODIFY RDB$RELATION_FIELDS failed
no permission for control access to TABLE TAGS
I had already granted ALL privileges to this user, also REFERENCES privileges, but I still getting this error.
Does anybody knows how to solve this?
I use Firebird 1.5
Thanks
The Firebird 2.5 Language Reference section on ALTER TABLE states:
Only the table owner and administrators have the authority to use
ALTER TABLE.
In other words if you are not the owner of the table, you need to either login as SYSDBA, or you need to be logged in as root or Adminstrator on the machine with the database. There is - as far as I am aware - no other way to alter a table as a different user.
In Firebird 2.5 there is also the RDB$ADMIN role which allows a user which is granted this role to act with the same rights as SYSDBA.
The rights you can GRANT (except for REFERENCES) are only for DML, not for DDL operations.
Firebird 3 introduced metadata privileges, which allows you to grant these permissions to a specific user or role for specific object types.
For example:
GRANT ALTER ANY TABLE TO Joe;
Will allow the user Joe to alter any tables in the current database.