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

🐛 Bug: Using a Different Postgres Schema Breaks Table Renaming #8524

Open
1 task done
ProjectMoon opened this issue May 18, 2024 · 0 comments
Open
1 task done

🐛 Bug: Using a Different Postgres Schema Breaks Table Renaming #8524

ProjectMoon opened this issue May 18, 2024 · 0 comments

Comments

@ProjectMoon
Copy link

Please confirm if bug report does NOT exist already ?

  • I confirm there is no existing issue for this

Steps to reproduce ?

  1. Create a separate schema in the Postgres DB that NocoDB will use (e.g. create schema nocodb). Grant privileges on the schema to the NocoDB user (grant all privileges on nocodb to nocodb_user).
  2. Install NocoDB pointing to a separate schema in Postgres, rather than public. Following the above example, this was accomplished by using ALTER ROLE nocodb_user SET search_path = nocodb;
  3. Create a table in a base.
  4. Attempt to rename table.

It seems that the rename operation is attempting to explicitly look for the table to rename in the public schema. Whereas in this case, the table is in a different schema. Everything else I've used so far appears to work when pointing the DB user's search path to a separate schema, just not table rename.

Desired Behavior

The table should be renamed.

Project Details

Node: v18.5.0
Arch: x64
Platform: linux
Docker: false
RootDB: pg
PackageVersion: 0.207.1

Attachments

Logs:

error: alter table "public"."nc_huan___Values" rename to "nc_huan__Foreign Currency Values" - relation "public.nc_huan___Values" does not exist
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 🏌️ Open
Development

No branches or pull requests

1 participant