Thoughts regarding pg_dump

From: "Rod Taylor" <rbt(at)zort(dot)on(dot)ca>
To: <pgsql-hackers(at)postgresql(dot)org>
Subject: Thoughts regarding pg_dump
Date: 2000-12-24 22:00:08
Message-ID: 012801c06df4$e171e700$6500000a@jester
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 Content-Type Size
Taylor, Rod B.vcf text/x-vcard 451 bytes

Browse pgsql-hackers by date

  From Date Subject
Next Message Alfred Perlstein 2000-12-25 03:04:03 Re: Upper limit on number of buffers?
Previous Message Brent Verner 2000-12-24 20:14:19 Re: Re: 7.1 on DEC/Alpha