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
Unsupported DO...END block in migration #651
Comments
@gorbak25 thanks for the bug report. could you include the sql of the migration please the error message mentions the use of do blocks... the proxy disallows these because the sql parser doesn't read the body of the do and so we can't figure out what's being done in order to capture the operations. is there any driving need to use a do block for your migration? The above seems to be checking for the existence of the |
@magnetised Thanks for getting back to me! I've got 2 places where I'm using The first one was used in 0.6.3 to electrify the tables and this bug report refers to it DO $$
DECLARE
schema_exists BOOLEAN;
BEGIN
SELECT EXISTS (
SELECT 1
FROM information_schema.schemata
WHERE schema_name = 'electric'
) INTO schema_exists;
IF schema_exists THEN
CALL electric.electrify('public."DataTable"');
CALL electric.electrify('public."Column"');
CALL electric.electrify('public."IntegrationInstance"');
CALL electric.electrify('public."ColumnReference"');
CALL electric.electrify('public."Row"');
CALL electric.electrify('public."CellValue"');
-- Hotfix the electric schema
ALTER TABLE electric.ddl_commands
DROP CONSTRAINT ddl_table_unique_migrations;
CREATE EXTENSION IF NOT EXISTS pgcrypto;
ALTER TABLE electric.ddl_commands
ADD COLUMN query_digest text GENERATED ALWAYS AS (digest(query, 'shake128')) STORED;
ALTER TABLE electric.ddl_commands ADD CONSTRAINT ddl_table_unique_migrations UNIQUE (txid, txts, version, query_digest);
END IF;
END $$; Fortunately after converting it to ALTER TABLE public."DataTable" ENABLE ELECTRIC;
ALTER TABLE public."Column" ENABLE ELECTRIC;
ALTER TABLE public."IntegrationInstance" ENABLE ELECTRIC;
ALTER TABLE public."ColumnReference" ENABLE ELECTRIC;
ALTER TABLE public."Row" ENABLE ELECTRIC;
ALTER TABLE public."CellValue" ENABLE ELECTRIC; it just works. The second occurrence unfortunately is not easy to get rid off. I've got some helper tables maintained using triggers and i want for ON DELETE CASCADE triggers to work on them during logical replication. To achieve that I'm dynamically generating sql which will enable the triggers: DO $$
DECLARE
rec RECORD;
v_sql TEXT;
BEGIN
-- Enables ON DELETE CASCADE ON UPDATE CASCADE triggers during logical replication
FOR rec IN (
SELECT 'ALTER TABLE "' || s1.t || '" ENABLE ALWAYS TRIGGER "' || s1.tgname || '";' AS sql
FROM
(
SELECT 'CellValue' AS t, tgname FROM pg_trigger WHERE tgrelid='"CellValue"'::regclass AND tgconstrrelid='"CellValueForEvaluation"'::regclass
UNION
SELECT 'DataTable' AS t, tgname FROM pg_trigger WHERE tgrelid='"DataTable"'::regclass AND tgconstrrelid='"DataTableTopoColumnOrder"'::regclass
) AS s1
)
LOOP
v_sql := rec.sql;
EXECUTE v_sql;
END LOOP;
END $$; Is there an alternative to this? PS. I've managed to get my app running on 7.1 by splitting the schema into 2 parts - one for the proxy, the second one for postgres. |
@gorbak25 glad you got it to work. The problem with do blocks is that, because they allow for full plpgsql programs, not just sql statements, it's nigh on impossible for us to extract the actual ddl statements out of them, which means we can't do our syntax re-writing or various validations. however, your use case above is valid. I'm thinking perhaps some Will think about it and come back to you. You shouldn't have to split the migrations like that. |
|
I just ran into this problem as well, while running Oban migrations. I initially thought it was coming from functions I'm writing in plpgsql, but I see now DO END blocks in Oban's migrations. Are DO END blocks not allowed? Are there any other limitations I should be aware of related to the use of plpgsql? Thank you. |
For reference, here is what the Oban migration is trying to execute.
Also regarding overall plpgsql support, we make pretty extensive use of plpgsql in our project, but if I temporarily comment out all Oban migration code, I get through all of our migrations, so from what I'm seeing so far it seems DO END blocks are the only issue. |
@justindotpub We will support passthrough for DO...END blocks one way or another. We just haven't come up with a satisfactory design for it yet. You can work around this limitation in the proxy by applying some migrations directly to Postgres while still using the Proxy for migrations that touch electrified schema. |
Migrations are also generated with this syntax by DrizzleORM for enum types DO $$ BEGIN
CREATE TYPE "objective_state" AS ENUM('open', 'closed');
EXCEPTION
WHEN duplicate_object THEN null;
END $$; |
The text was updated successfully, but these errors were encountered: