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, Pennsylvania 19026

Mon, 13 Dec 1999 18:02:54 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Followup to my bug report
Hmmm, I thought I had tested for that. It seemed to me that functions were evaluated
at run-time, so any reference in a function to a table would not be noticed until
that function was actually called (this is for PL/pgsql where I know that even stupid
syntax errors are not caught until run-time). The SQL parser, however, does check
that the function exists before one can create the table...

Thank you for following up on this.
Mark

Bruce Momjian wrote:

> 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, Pennsylvania 19026

--
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)




Mon, 13 Dec 1999 15:32:42 -0800
Mark Dalphin <mdalphin@amgen.com>
Re: Followup to my bug report