Re: Followup to my bug report

From: Mark Dalphin <mdalphin(at)amgen(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Followup to my bug report
Date: 1999-12-13 23:32:42
Message-ID: 3855821A.ADE6ECA0@amgen.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)amgen(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)amgen(dot)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)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-12-14 00:00:49 Re: [HACKERS] update_pg_pwd
Previous Message Peter Eisentraut 1999-12-13 23:28:50 Re: [HACKERS] update_pg_pwd