Thread: Thoughts regarding pg_dump

Thoughts regarding pg_dump

From
"Rod Taylor"
Date:
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.
Attachment