Re: pg_dump performance lossage for primary keys
От | Ross J. Reedstrom |
---|---|
Тема | Re: pg_dump performance lossage for primary keys |
Дата | |
Msg-id | 20010403150100.D24063@rice.edu обсуждение исходный текст |
Ответ на | Re: pg_dump performance lossage for primary keys (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, Apr 03, 2001 at 03:34:51PM -0400, Tom Lane wrote: > Philip Warner <pjw@rhyme.com.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
В списке pgsql-hackers по дате отправления: