On 12/9/2008 4:28 PM, Mark Stosberg wrote:
> On Mon, 8 Dec 2008 16:44:26 -0500
> Mark Stosberg <mark at summersault.com> wrote:
> 
>> > Your script would need to do something like:
>> > 
>> >   alter table this...
>> >   alter table that...
>> >    ... and onwards, for the "cast of 11 tables" ...
>> > 
>> > ... then, still as part of the same DDL script being executed by EXECUTE 
>> > SCRIPT...
>> >   update "_my_slony_schema".sl_table
>> >    set tab_relname = (select relname from pg_catalog.pg_class p where 
>> > oid = tab_reloid);
>> >   update "_my_slony_schema".sl_sequence
>> >    set seq_relname = (select relname from pg_catalog.pg_class p where 
>> > oid = seq_reloid);
>> > 
>> > Note this affects sequences *and* tables.
>> 
>> This looks logical to me. However, I was surprised to find that none of
>> my OIDs lined up for these two tables (with PostgreSQL 8.3.3):
>> 
>>   SELECT oid FROM pg_catalog.pg_class p WHERE relname = 'pets';
>>   SELECT tab_reloid from _my_schema.sl_table where tab_relname = 'pets';
>> 
>> I reviewed the docs for "pg_class" myself, and it looks to me like your
>> query would be correct.     
> 
> This was a development setup, and it turned out we needed to run "REPAIR
> CONFIG". After that, the OIDs lined up again.

I would assume from this that said tables have been dropped and 
recreated before, which is pretty much the only way a tables 
pg_class.oid can ever change.


Jan

-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin