In between migration from Oracle to Postgres, I need to execute some insert statement for an Oracle table from Postgres (in which the primary key field is using a sequence for uniqueness).
Now at the time of the migration I am converting some procedure that is used to insert a row in a table, but I can't move table directly from oracle to Postgres due to a higher dependency on the table.
That's why I need to execute an Oracle sequence from Postgres.
The simplest solution is probably to create a view in Oracle that doesn't contain the column that is to be filled from the sequence.
Then define a trigger on the table that fills the column from the sequence when NULL and creare a foreign table on the view.
Wheb you INSERT into the foreign table, the column will get filled by the trigger.
Related
I would like to add a generated column to a very large table without locking it:
alter table customer alter column foo text generated always as ((infos_json->'customerinfos'->>'redirect')) stored;
Is there a way to do this without locking? Maybe concurrently?
I am using ora2pg to export TABLE and INSERT type from oracle database. https://ora2pg.darold.net/documentation.html#:~:text=Ora2Pg%20consist%20of,QUERY%2C%20KETTLE%2C%20SYNONYM.
I have 2 questions.
The TABLE and INSERT sql statements have double quotes for table and column names but I want to create them without double quotes. Is it possible to configure this in the .conf file?
The INSERT sql file that is generated by ora2pg does not have the sql statements in right order. The parent table data should be inserted first before trying to insert data into child table due to foreign key constraints. But the INSERT sql file generated by ora2pg is not taking this into account so this is causing error because the child table insert statement is present before the parent table. Is this how ora2pg works or am I doing something wrong in the .conf file?
Is there a method to do an ALTER COLUMN in postgres 12 on an huge table without waiting a lifetime?
I try to convert a field from bigint to smallint :
ALTER TABLE huge ALTER COLUMN result_code TYPE SMALLINT;
It takes 28 hours, is there a smarter method?
The table has sequences, keys and foreign keys
The table has to be rewritten, and you have to wait.
If you have several columns whose data type you want to change, you can use several ALTER COLUMN clauses in a single ALTER TABLE statement and save time that way.
An alternative idea would be to use logical replication: set up an empty copy of the database (pg_dump -s), where your large table is defined with smallint columns. Replicate your database to that database, and switch over as soon as replication has caught up.
I would like to rename a column in DB2 on the iSeries platform. The link below is related, however, I do not have a primary key or constraint defined on the columns I would like to rename. In addition, I'm not certain that they are on the iSeries as well.
Rename column in DB2
However, I decided to give it a go with the following statement:
ALTER TABLE MYLIB.MYFILE RENAME COLUMN COL0001 TO COL0002;
Post execution, I am given the following warning:
Additionally, I do not see a RENAME COLUMN in the docs:
https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_71/db2/rbafzatabl.htm
Is this something that is not possible on V7R1 DB2?
There is no RENAME COLUMN clause in the ALTER TABLE statement in DB2 for IBM i.
You may probably achieve the same with the following:
ALTER TABLE MYLIB.MYFILE ADD COLUMN COL0002 ...;
UPDATE MYLIB.MYFILE SET COL0002 = COL0001;
ALTER TABLE MYLIB.MYFILE DROP COLUMN COL0001;
My database has severals table with some column type 'money'. I would like to alter all these columns (in different tables) in a single statement rather than change type column by column, to avoid omissions.
You'll have to repeat the altering query for every column.
You might want to create a program code to do that for you. You know, with loops.
In order for the database to alter all the tables atomically you should enclose all the altering queries in a transaction (PostgreSQL supports transactional DDL).