Yes, you're right, that's a bug; fixed in cvs. Though I consider a table without PK or OID buggy too... :-) We might expand pgAdmin3 to use a unique key as PK replacement.
phpPgAdmin does the following in order to find a unique row identifier:
1. Looks for a PK
2. Looks for a Unique index. If one is found, editing rows is possible unless the entry in the index for the row is NULL (because there can be multiple NULLs in a unique index)
3. Looks for an OID column. If one exists, editing is possible BUT the update or delete of the row is performed in a transaction and if more than one row is modified then the alteration is rolled back. This is important as OID columns can contain duplicate entries in the case of OID wraparound.
You know, phpPgAdmin and pgAdmin really should share a lot more :)
I think I'll look at the pgAdmin3 column type alteration code. You might be interested in phpPgAdmin's Find Object code...
Actually, are you guys BSD licensed or GPL'd? phpPgAdmin is GPL'd.
Chris
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
