Skip site navigation (1) Skip section navigation (2)

Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore

From: Joel Burton <jburton(at)scw(dot)org>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, PostgreSQL HACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore
Date: 2001-04-20 17:04:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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(at)scw(dot)org>
Director of Information Systems, Support Center of Washington

In response to

pgsql-hackers by date

Next:From: Vince VielhaberDate: 2001-04-20 17:10:57
Subject: Re: Docs on web site
Previous:From: Thomas LockhartDate: 2001-04-20 16:49:05
Subject: Docs on web site

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group