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

Поиск
Список
Период
Сортировка
От Joel Burton
Тема Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore
Дата
Msg-id Pine.LNX.4.21.0104201259220.1776-100000@olympus.scw.org
обсуждение исходный текст
Ответ на Re: Re: [BUG?] tgconstrrelid doesn't survive a dump/restore  (Philip Warner <pjw@rhyme.com.au>)
Список 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 по дате отправления:

Предыдущее
От: Thomas Lockhart
Дата:
Сообщение: Docs on web site
Следующее
От: Vince Vielhaber
Дата:
Сообщение: Re: Docs on web site