-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[YSQL] Feature support - ALTER TABLE #1124
Comments
Summary: Enabled DROP CONSTRAINT IF EXISTS in the parser and added a test in yb_feature_alter_table Test Plan: Added test for DROP CONSTRAINT IF EXISTS in yb_feature_alter_table Reviewers: neha Reviewed By: neha Subscribers: yql Differential Revision: https://phabricator.dev.yugabyte.com/D6474
Also fails to work with queries like below - |
@dodilp - FOREIGN KEY is being implemented as we speak. Hope to have it in a few weeks. |
Fails for ALTER TABLE OWNER not supported yet |
For us we are getting the following running migrations from Entity Framework: Failed executing DbCommand (10ms) [Parameters=[], CommandType='Text', CommandTimeout='30'] |
Fails to be used as https://www.metabase.com/'s relational database backend. 2-10 09:15:02 ERROR changelog.ChangeSet :: Change Set migrations/000_migrations.yaml::23::agilliland failed. Error: ERROR: ALTER TABLE ALTER column not supported yet |
+1 For this issue cause I can't restore my dump for this |
@irizzant which exact statement is blocking you ? |
|
@irizzant I don't think we use index-statistics like in postgresql. Can you comment that statement and continue migration and see if there's anything else blocking you ? |
@ddorian not an easy task, I have a whole company db dump I have to try and search/replace for occurrences is not feasible. |
+1 |
+1 |
Good work guys, i can not migrate my schema for the following reason, is there a way around this? |
Hey @uwejan, would you mind posting the exact command you're executing and YB version you're using on our community slack or forum so we could give you more detailed answer? |
@frozenspider Hi, i have posted on slack. Thank you. |
+1 for support for: "ALTER TABLE name CLUSTER ON" I'm looking to use yugabytedb as a stand-in for pgsql for an existing application. I'm looking to see if I can modify the application & schema as needed, but obviously it'd be easier for me to use yugabytedb as a 'drop-in' replacement if it did not throw an unsupported error. |
@dbotwinick the tables & indexes are clustered on disk by default https://docs.yugabyte.com/latest/architecture/docdb/ by the PRIMARY KEY. And I don't think there's a chance in the near/medium term to support clustering on something else besides the primary key. So for now you can just ignore this error. We'll look internally into enabling it and making it a no-op for now. |
@ddorian that would work for me! I haven't done particular testing on the performance implications that could possibly come up here... but my gut feeling is that it wouldn't particularly be a problem in this case. Ideally I could just use the vanilla application without modification, so if it were a no-op and it logs a warning or something--that would be sufficient for my purposes. It would also work for me if there were some sort of configuration flags to switch between no-op while logging issue and throwing an error. I don't know how treating it as a no-op might cause trouble for others, so it might be safer to make it a configurable option so that the defaults are safer? (although that comes with its own issues) |
+1 I can't migrate from my dump ERROR: ALTER TABLE ALTER column not supported yet CREATE TABLE public.event_search (
event_id text,
room_id text,
sender text,
key text,
vector tsvector,
origin_server_ts bigint,
stream_ordering bigint
);
ALTER TABLE ONLY public.event_search ALTER COLUMN room_id SET (n_distinct=-0.01); |
Hi @pcmid
Can you explain the use case behind manually changing the statistics? Do you know in advance the number of unique values in the column? |
Thanks for reply. The reason is here. |
@pcmid probably yes, you can ignore it in this case. |
Is this implemented? |
can you provide the full sql migration? |
I'm seeing this in a real world scenario upon schema installation, see https://github.com/element-hq/synapse/blob/master/synapse/storage/schema/state/full_schemas/72/full.sql.postgres#L23 Are there any workarounds available on Yugabyte side? I could obviously change the schema to make it compatible, but then I couldn't rely on Synapse schema upgrades going forward... |
There are no current workarounds. You can make a fork of synapse and just comment that part and you still can rely on them for the other upgrades. You can also subscribe to issue #16675 for updates. |
+1 for alter table column set (fillfactor = 75); |
Related: #23889 |
Jira Link: DB-1178
This is a master issue that keeps track of
ALTER TABLE
variants.The checkmark means that the statement is already supported.
Add / remove / rename columns, constraints
Alter columns
Triggers, partitions and tablespaces
Ownership and row level security
Misc: schema, rules, IODs, table inheritance, clustering etc
The text was updated successfully, but these errors were encountered: