Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore - Mailing list pgsql-hackers

From Joel Burton
Subject Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore
Date
Msg-id Pine.LNX.4.21.0104201259220.1776-100000@olympus.scw.org
Whole thread Raw
In response to Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore  (Philip Warner <pjw@rhyme.com.au>)
List pgsql-hackers
On Sat, 21 Apr 2001, Philip Warner wrote:

> At 11:29 20/04/01 -0500, Jan Wieck wrote:
> >Philip Warner wrote:
> >> At 08:42 19/04/01 -0500, Jan Wieck wrote:
> >> >    and  the required
> >> >    feature to correctly restore the tgconstrrelid is already  in
> >> >    the  backend,  so  pg_dump  should make use of it
> >>
> >> No problem there - just tell me how...
> >
> >    Add  a  "FROM <opposite-relname>" after the "ON <relname>" to
> >    the CREATE CONSTRAINT TRIGGER statements. That's it.
> >
> 
> I'll make the change ASAP.

Woo-hoo! Thanks.

I posted a plpgsql script yesterday that tries to restore the name if it's
already been lost to a dump/restore cycle.

It would be a more robust solution if, instead of relying on pgconstrname,
I could get into the trigger arguments. However, these does not seem to be
any way for me to do this from plpgsql, as the functions for manipulating
bytea fields aren't very useful for this, an I can't coerce bytea into
text or anything like that.

Can anyone offer help on this? If I can get into the real args, I'll fix
up the script so that it can be run once by the people w/o tgconstrrelid,
and then, once Philip's done his work, we'll never lose it again! :-)

-- 
Joel Burton   <jburton@scw.org>
Director of Information Systems, Support Center of Washington



pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Docs on web site
Next
From: Vince Vielhaber
Date:
Subject: Re: Docs on web site