Skip to content

GatorSet table features

This guide explains, in simple terms, what table features the service will recreate in your target database when you move data between relational systems via the UI. You don’t need to know how it’s implemented; the goal is to set expectations for what your new target table will contain.

Key notes

  • Source and target must be the same DB type to fully clone structure (Oracle → Oracle, SQL Server → SQL Server, PostgreSQL → PostgreSQL, IBM Db2 → IBM Db2).
  • Data is written via JDBC; we also apply DDL to mirror as much of the table definition as possible.
  • In general we copy: columns, data types, defaults, nullability, primary keys, unique keys, foreign keys, check constraints (varies per DB), plain indexes, column comments, identity/auto-increment columns, hidden/invisible columns where supported, tablespace (where applicable), some grants/privileges (Oracle, Db2), and Oracle partitions/subpartitions.
  • Example SQLs below are illustrative and trimmed for clarity.

Oracle:

Oracle What we copy

  • Columns with data types and defaults.
  • Nullability (NOT NULL).
  • Primary keys, unique constraints.
  • Foreign keys.
  • Check constraints.
  • Plain (non-constraint) indexes.
  • Column comments.
  • Identity columns (GENERATED ALWAYS/BY DEFAULT AS IDENTITY + options).
  • Hidden/invisible columns: preserved as Invisible.
  • Tablespace (if present on the table/index) where available from metadata.
  • Grants/privileges to valid grantees (if available).
  • Triggers (table triggers) are recreated by extracting their DDL and adapting the schema reference.
  • Partitions and subpartitions:
  • RANGE, LIST, HASH partitioning supported.
  • Interval partitioning: creates the seed partition; further interval partitions are created automatically by Oracle.
  • Subpartitioning (HASH and RANGE) where defined.

What we do not copy

  • Table compression settings (e.g., OLTP/Advanced Compression) are not migrated.
  • Storage parameters not present in standard metadata extracts.

Small examples

  • Table creation with PK and column default CREATE TABLE "HR"."EMP" ( "EMP_ID" NUMBER GENERATED BY DEFAULT AS IDENTITY, "NAME" VARCHAR2(100) NOT NULL, "DEPT_ID" NUMBER, "ACTIVE" CHAR(1) DEFAULT 'Y' NOT NULL, CONSTRAINT "PK_EMP" PRIMARY KEY("EMP_ID") ) TABLESPACE "USERS";
  • Comment on a column COMMENT ON COLUMN "HR"."EMP"."NAME" IS 'Employee full name';
  • Foreign key ALTER TABLE "HR"."EMP" ADD CONSTRAINT "FK_EMP_DEPT" FOREIGN KEY("DEPT_ID") REFERENCES "HR"."DEPT"("DEPT_ID") ENABLE;
  • Plain index CREATE INDEX "IDX_EMP_NAME" ON "HR"."EMP" ("NAME");
  • Range partitioning (seed; interval handled by Oracle later) CREATE TABLE "HR"."SALES" ( "ID" NUMBER, "TXN_DATE" DATE ) PARTITION BY RANGE ("TXN_DATE") ( PARTITION P1 VALUES LESS THAN (DATE '2023-01-01') TABLESPACE "TS1" );

SQL Server

SQL Server What we copy

  • Columns with data types and defaults.
  • Nullability (NULL/NOT NULL).
  • Primary keys, unique constraints.
  • Foreign keys.
  • Check constraints (WITH CHECK/NOCHECK state preserved when available).
  • Plain (non-constraint) nonclustered indexes.
  • Column comments (MS_Description extended properties).
  • Identity columns (IDENTITY(seed, increment)).

What we do not copy

  • Index options not present in the metadata scope (e.g., INCLUDE columns, filters, fillfactor) are not replicated.
  • Filegroups and advanced storage options not in standard metadata.

Small examples

  • Table creation with identity and PK CREATE TABLE [dbo].[Emp] ( [EmpId] INT IDENTITY(1,1) NOT NULL, [Name] NVARCHAR(100) NOT NULL, [DeptId] INT NULL, CONSTRAINT [PK_Emp] PRIMARY KEY ([EmpId]) );
  • Column comment EXEC sp_addextendedproperty @name = N'MS_Description', @value = 'Employee full name', @level0type = N'SCHEMA', @level0name = N'dbo', @level1type = N'TABLE', @level1name = N'Emp', @level2type = N'COLUMN', @level2name = N'Name';
  • Foreign key ALTER TABLE [dbo].[Emp] WITH CHECK ADD CONSTRAINT [FK_Emp_Dept] FOREIGN KEY ([DeptId]) REFERENCES [dbo].Dept;
  • Plain index CREATE NONCLUSTERED INDEX [IX_Emp_Name] ON [dbo].Emp;

PostgreSQL

PostgreSQL What we copy

  • Columns with data types and defaults.
  • Nullability (NOT NULL).
  • Primary keys, unique constraints.
  • Foreign keys.
  • Check constraints (table-level checks where present).
  • Column comments.
  • Identity columns (GENERATED ALWAYS/BY DEFAULT AS IDENTITY with options).

What we do not copy

  • Storage parameters (e.g., fillfactor) and special index types not discovered in the common metadata path.
  • Tablespace specifics beyond table-level tablespace if available.

Small examples

  • Table creation with identity and PK CREATE TABLE public.emp ( emp_id bigint GENERATED BY DEFAULT AS IDENTITY, name varchar(100) NOT NULL, dept_id int, CONSTRAINT pk_emp PRIMARY KEY (emp_id) );
  • Column comment COMMENT ON COLUMN public.emp.name IS 'Employee full name';
  • Foreign key ALTER TABLE public.emp ADD CONSTRAINT fk_emp_dept FOREIGN KEY (dept_id) REFERENCES public.dept(dept_id);
  • Plain index (example) CREATE INDEX ix_emp_name ON public.emp (name);

IBM Db2

IBM Db2 What we copy

  • Columns with data types and defaults.
  • Nullability (NOT NULL / enforced status where applicable).
  • Primary keys, unique constraints.
  • Foreign keys.
  • Check constraints.
  • Plain (non-constraint) indexes.
  • Column comments.
  • Identity columns (GENERATED BY DEFAULT/ALWAYS AS IDENTITY).
  • Grants/privileges for valid grantees (SELECT/INSERT/UPDATE/DELETE/ALTER/INDEX/REFERENCES/CONTROL as discovered) when available.

What we do not copy

  • Advanced storage and tablespace details not present in standard metadata.
  • Stored procedures and functions: 
  • Views
  • Sequences
  • Triggers
  • Hidden columns

Small examples

  • Table creation with identity and PK CREATE TABLE "HR"."EMP" ( "EMP_ID" INTEGER GENERATED BY DEFAULT AS IDENTITY, "NAME" VARCHAR(100) NOT NULL, "DEPT_ID" INTEGER, CONSTRAINT "PK_EMP" PRIMARY KEY ("EMP_ID") );
  • Column comment COMMENT ON COLUMN "HR"."EMP"."NAME" IS q'[Employee full name]';
  • Foreign key ALTER TABLE "HR"."EMP" ADD CONSTRAINT "FK_EMP_DEPT" FOREIGN KEY ("DEPT_ID") REFERENCES "HR"."DEPT" ("DEPT_ID");
  • Plain index CREATE INDEX "IX_EMP_NAME" ON "HR"."EMP" ("NAME");
  • Grants (example; only for valid grantees) GRANT SELECT,INSERT,UPDATE ON TABLE "EMP" TO USER "REPORTING_APP";

Other notes and behaviors

  • Hidden/Invisible columns (Oracle, some Db2 variants): the service temporarily toggles status to move data safely and then restores visibility to match the source.
  • Identity/Serial columns: temporarily adjusted when needed to allow inserts, then restored to match source behavior.
  • Write order: tables are created/loaded in a dependency-aware order (child tables after parent tables for FK integrity) where possible.
  • If the source and target connections are the same, and no columns are selected in the UI for a table, that table is skipped.

Limitations recap

  • Oracle compression is not migrated.
  • Database-specific features that require vendor tools or proprietary options beyond commonly available metadata are out of scope.

Questions? If you’re unsure whether a specific feature on your source table will be present in the target, please raise an issue with a sample table definition, and we’ll confirm how it’s handled.