Re: Table constraint ordering disrupted by pg_dump

Patricia Holben <pholben(at)greatbridge(dot)com> writes:
> I have loaded this new version and re-tested but don't see it fixed.

It looks fixed to me. Original SQL in constraints.sql:

CREATE TABLE INSERT_TBL (x INT DEFAULT nextval('insert_seq'),
y TEXT DEFAULT '-NULL-',
z INT DEFAULT -1 * currval('insert_seq'),
CONSTRAINT INSERT_CON CHECK (x >= 3 AND y <> 'check failed' AND x < 8),
CHECK (x + z = 0));

As dumped by current-CVS pg_dump:

CREATE TABLE "insert_tbl" (
"x" integer DEFAULT nextval('insert_seq'::text),
"y" text DEFAULT '-NULL-',
"z" integer DEFAULT (-1 * currval('insert_seq'::text)),
CONSTRAINT "insert_con" CHECK ((((x >= 3) AND (y <> 'check failed'::text)) AND (x < 8))),
CHECK (((x + z) = 0))
);

> I do have a separate routine which I am running - it isn't complete which
> is why I haven't shared it yet - which proves that when the dump is
> reloaded the constraints are not applied in the original order.

I notice that the backend tends to apply the constraints in the reverse
order of declaration, but this should be consistent between the original
database and the dumped/reloaded one.

regards, tom lane