We did discuss this. It seems there is circular dependency about
dumping functions and tables, where some rely on the other. We
discussed this, and the only fix we can think of is to dump the entries
in creation order, using the oid as a guide.
Not sure when we can implement this.
> Hi Bruce,
>
> Sorry to bother you personally, but as you are keeper of the "To Do" list, I
> thought I would check with you directly rather than clutter up the Postgresql
> mail lists.
>
> Some time ago I submitted a bug report about PostgreSQL pg_dump. I would forward
> you a copy of my e-mail if I could find one.
>
> The essence of the report was that the order of the dumped items from pg_dump
> made a direct reload (without hand editing the dump) impossible.
>
> The case I stumbled on was something like:
>
>
> > CREATE Function MyTimeStamp (what ever);
> >
> > CREATE TABLE MyTable (
> > key int PRIMARY KEY,
> > add_date timestamp DEFAULT MyTimeStamp()
> > );
> >
> The problem is that pg_dump dumps the Functions after the Tables, so when
> re-loading, the above table definition fails (it doesn't know about the function
> MyTimeStamp() at the time of creation).
>
> There were no comments about my report at the time I made it, so I was concerned
> that the HACKERs may have missed it. With a major release "just now coming", I
> thought I should re-port the report.
>
> Hope this helps,
> Mark
>
> --
> Mark Dalphin email: mdalphin@amgen.com
> Mail Stop: 29-2-A phone: +1-805-447-4951 (work)
> One Amgen Center Drive +1-805-375-0680 (home)
> Thousand Oaks, CA 91320 fax: +1-805-499-9955 (work)
>
>
>
>
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
