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: Pine.LNX.4.21.0104201259220.1776-100000@olympus.scw.org
Views: Raw Message | Whole Thread | Download mbox
Thread:
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

Browse pgsql-hackers by date

  From Date Subject
Next Message Vince Vielhaber 2001-04-20 17:10:57 Re: Docs on web site
Previous Message Thomas Lockhart 2001-04-20 16:49:05 Docs on web site