| From: | "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: pg_dump performance lossage for primary keys |
| Date: | 2001-04-03 20:01:00 |
| Message-ID: | 20010403150100.D24063@rice.edu |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Apr 03, 2001 at 03:34:51PM -0400, Tom Lane wrote:
> Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
>
> > We really need ALTER TABLE ADD CONSTRAINT for PK.
>
> That would be a cleaner way to do it, all right ... but for now, you can
> just reach in and set the indisprimary flag in pg_index after creating
> the index. I'm visualizing
>
<snip>
>
> On the other hand, that would fall over if executed by a non-superuser.
> Drat. Okay, I guess we just have to leave this as a TODO item for now.
This is one of those 'dual roles of pg_dump' problems: Philip has been
slowly migrating it from being a 'quickest possible backup dump' tool
to a 'recover my db in as human friendly (and SQL standards compliant)
a format as possible' tool. Which, not coincidently, has dramatically
reduced the version fragility of the dump output.
Adding implementation specific performance hacks back in is probably
a necessary evil, but should probably be protected by a '--fastdump'
switch or some such.
Ross
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Myers | 2001-04-03 21:10:12 | Re: Final call for platform testing |
| Previous Message | Tom Lane | 2001-04-03 19:34:51 | Re: pg_dump performance lossage for primary keys |