Support for renaming a view

[kgodey]

The Mathesar UI should allow users to rename existing views.

Scenario

The user wants to rename a view. We allow them to enter a new name and rename the view.

Error scenarios:

• The name entered is an invalid name for the view. Cases for invalid name include:
  • View name is too long
  • View name is already taken by another object
• View rename fails in the backend.

Additional context

• Blocked by design work on Support for opening and interacting with a View #466

[kgodey]

@dmos62 @ghislaineguerin @pavish @mathemancer @seancolsen @silentninja This issue has been updated and is ready for review. Please look through it and unassign yourself after you've added any feedback that you might have.

[dmos62]

This might be tangential, but what's our strategy for dealing with database object names (e.g. view names)? Postgres puts constraints on names that might not necessarily make sense for a Mathesar user (right?). We can hide that inconvenience by using a mapping from user-specified-alias to database-object-name. The database-object-name can be automatically generated or chosen by the user. A user-specified-alias can be provided for an inconveniently named database-object whose database-name can't be changed due to something else (maybe outside Mathesar) relying on it.

[kgodey]

This might be tangential, but what's our strategy for dealing with database object names (e.g. view names)?

Currently, we're using the names that Postgres uses. We considered having the concept of "human readable names" but discarded it for simplicity. I think we can add aliases in the future (post-alpha) if needed.

[mathemancer]

@dmos62

Postgres puts constraints on names that might not necessarily make sense for a Mathesar user (right?).

Not quite. The traditional SQL constraints on identifiers are still in play, but PostgreSQL has a way to get around them. Any character included in the DB's character set (except the null character) is valid in a name if it's a so-called 'quoted identifier' in the DB. For input of such an identifier, you need to wrap it in double-quotes. We're doing this quoting silently. So, the user doesn't need to worry about that unless they're also using the DB from another client, which may mean they'd need to quote some identifiers manually. For example,

CREATE TABLE "😃😃😃" ("🙃🙃" VARCHAR, "VARCHAR" NUMERIC);

is perfectly valid in PostgreSQL (assuming your locale supports UTF-8), and creates a table named 😃😃😃 with two columns:

• the first named 🙃🙃 of type VARCHAR, and
• the second named VARCHAR of type NUMERIC.

Note that the quotes are not stored as part of the name; they're just a signal to the input parser that the enclosed string is an identifier.

The locale is a bit different, and may be tricky. If the client (e.g., the Mathesar web client) and the DB are on the same Locale, there's no problem. Also, there's no problem if their locales share the same character set (except some potential confusion around sorting). If, however, the web client and the DB don't share a character set, and some non-shared characters are either present in the DB, or input from the client, I expect weird things to happen.

In reality, the most common locale for a PostgreSQL installation is using the C locale, which supports UTF-8, and most browsers are also using (or at least supporting) UTF-8. So, the times when the user will need to worry too much about what characters they're using for input are pretty rare.

Relevant pages from the docs:

• https://www.postgresql.org/docs/13/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS
• https://www.postgresql.org/docs/13/multibyte.html

(In fact, the whole 4th chapter of the PostgreSQL docs is great, and does a good job of explaining many SQL details, and the places where PosgreSQL is different.

[mathemancer]

@kgodey relevant to my other comment: By "invalid name", do you just mean a view with the same name as another named object? Or were you thinking of other ways the name could be invalid? I'm assuming based on previous conversations you don't want to restrict users to traditional valid names as per the SQL standard.

[kgodey]

@mathemancer I was thinking about view names either having a name collision or being too long (over 63 bytes).

[mathemancer]

@mathemancer I was thinking about view names either having a name collision or being too long (over 63 bytes).

Ah, okay. We might consider separating those cases for user feedback in the UI. We can let them know without a call to the DB about the length (or just not let them keep typing), and then the collision could be after they click "save" or "submit" or whatever. Those being the invalid names makes sense, though.

[kgodey]

I updated the issue description with more details about invalid name errors. I'm marking this issue as ready for design and moving to the backlog.

[kgodey]

Closing this issue in favor of #466