|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|
|Views:||Raw Message | Whole Thread | Download mbox|
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.
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
|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|