[check_postgres] what to do with same_schema behaviour

[Cédric Villemain]

Hi,

same_schema action provide usefull output. 
But I am in case where I wonder what to do : a table foo on host A have one 
column get dropped. Then you start(init) replication to host B.

A et B hosts have same foo table schema, but same_schema action will complain 
wrong position for columns between hosts (correct from pg_attribute  point of 
view, not from real schema).

Ex:
If you drop the column at position 7 then init replication, on host A column 8 
keep on position 8, but will be 7 on host B.

This is because pg_attribute keep information on dropped column like this : 

select * from pg_attribute where attname like '%pg.dropped.10%';
-[ RECORD 1 ]-+------------------------------
attrelid      | 144060
attname       | ........pg.dropped.10........
atttypid      | 0
attstattarget | 0
attlen        | -1
attnum        | 7
attndims      | 0
attcacheoff   | -1
atttypmod     | -1
attbyval      | f
attstorage    | x
attalign      | i
attnotnull    | f
atthasdef     | f
attisdropped  | t
attislocal    | t
attinhcount   | 0

attnum is defined so same_schema will never succes.

So the issue is that schema are the same. I think that same_schema must not 
complain in this case. 

*But* same_schema should try to reorder by removing droppped column.

Agree ?

-- 
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : https://mail.endcrypt.com/pipermail/check_postgres/attachments/20091216/72b9c819/attachment.bin