Add UNIQUE and PRIMARY KEY to pg_get_constraintdef

Christopher Kings-Lynne writes:

This lets pg_get_constraintdef display the definitions for UNIQUE and
PRIMARY KEY constraints. It's a real shame this wasn't done for 7.3...

Are we now putting the pg_dump functionality into the backend? If not,
then I don't see the point. You extract this information with relative
ease from the system catalogs in any form that suits your needs.

--
Peter Eisentraut peter_e@gmx.net

Christopher Kings-Lynne writes:

This lets pg_get_constraintdef display the definitions for UNIQUE and
PRIMARY KEY constraints. It's a real shame this wasn't done for 7.3...

Are we now putting the pg_dump functionality into the backend? If not,
then I don't see the point. You extract this information with relative
ease from the system catalogs in any form that suits your needs.

Hrm - no. I'm just making it so that pg_get_constraintdef actually works on
all types of constraints in pg_constraint (which is the intended behaviour).

My comment about pg_dump was that if you look at how it dumps constraints,
it has to manually build UNIQUE, CHECK and PRIMARY KEY statements since
pg_get_constraintdef doesn't support those 3 types of constraint. If it had
originally, then that part of pg_dump could have been somewhat simplified.
However, since it wasn't, that old kludgy code has to remain there forever
:)

And then again, yes, we are putting pg_dump functionality in the backend -
the entire pg_get_*def series of functions is designed to do exactly that.

Chris

This lets pg_get_constraintdef display the definitions for UNIQUE and
PRIMARY KEY constraints. It's a real shame this wasn't done for 7.3...

Are we now putting the pg_dump functionality into the backend? If not,
then I don't see the point. You extract this information with relative
ease from the system catalogs in any form that suits your needs.

Oh, actually I think I might have misunderstood you. pg_get_constraintdef()
already exists, but will only dump FOREIGN KEY statements...

Chris