pg_class doesn't seem to have any pointers regarding if the name for an item was automatically generated or was given by the user. If it did store that as a bool, it could be determined whether to use:
CONSTRAINT "table_pkey" PRIMARY KEY ("table")
or
PRIMARY KEY ("table")
in a dump.
By not keeping the auto-generated names (and generating them again with the next creation) it should allow postgres to name things with a sequence number in them without the user getting miffed about it. If in the dump I see PRIMARY KEY("table") and the database already drops the keys on DROP TABLE, I don't care if it's named pg_325342_pkey internally or instead of something more legible.
This would help prevent the current issue with users replacing auto-named entities, or in my case prevent multiple auto-named entites recieving the same name (checks were doing this as I had given the table and column long names myself, PG created names which were duplicate). Took a little while to figure out why the CREATE TABLE wasn't working.
An addition to pg_relcheck along the same lines. Add a foreign key of pg_relcheck.OID called pg_attribute.rcrelid. When NULL we know that the attribute was added as a table clause rather than a column clause. This (I believe) combined with the above would enable pg_dump to more accurately rebuild the statement used to create the table in the first place, or atleast what a human is more likley to type in if they were rebuilding manually.
If the above makes sense with the backend logic, I'll start tinkering to see what I can get done.
P.S. Please bear with me, I might actually become useful in a few months once I've figured out enough of the PostgreSQL internals and C. Normally I'm coding embedded devices in assembly or higher level php / perl.
--
Rod Taylor
There are always four sides to every story: your side, their side, the truth, and what really happened.