Re: Followup to my bug report
От | Mark Dalphin |
---|---|
Тема | Re: Followup to my bug report |
Дата | |
Msg-id | 3855821A.ADE6ECA0@amgen.com обсуждение исходный текст |
Ответ на | Re: Followup to my bug report (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | 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@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)
В списке pgsql-hackers по дате отправления: