Re: [HACKERS] dump/reload

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: brett(at)work(dot)chicken(dot)org (Brett McCormick)
Cc: pgsql-hackers(at)hub(dot)org
Subject: Re: [HACKERS] dump/reload
Date: 1998-06-03 04:05:48
Message-ID: 199806030405.AAA26237@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> On Tue, 2 June 1998, at 22:19:01, Bruce Momjian wrote:
>
> > > they don't always work, in the case of a table with an attribute that
> > > calls a function for its default value.
>
> > This is a good point, and something worth thinking about. Maybe we
> > could scan through the defaults for a table, and call the dumpfunction
> > command for any functions. Then when they are later attempted to be
> > created, they would fail, or we could somehow mark them as already
> > dumped.
>
> Would we look at the binary plan (aiee!) or just try and parse the
> string value 'pg_attdef.adsrc` for a function call?
>

Just thought about it. With our new subselects we could:

select * from pg_proc where proid in (select deffunc from pg_class)
dump each func
dump tables
select * from pg_proc where proid not in (select deffunc from pg_class)
dump each func

This sounds like a winner. (I just made up the field names and stuff.)

Or are the oid's of the functions used in default values not immediately
available. Is that the binary plan you were talking about. That could
be very messy. Now I see pg_attrdef. This looks tough to grab function
names from.

Oh well.

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1998-06-03 04:09:07 Re: [HACKERS] dump/reload
Previous Message Brett McCormick 1998-06-03 03:28:06 keeping track of connections