Обсуждение: Delete icon deletes all records in pgadmin 1.61

Hi!

I have a table where the primary key is a serial but the position of the 
primary key is not the first column. Today when showing all recordsets 
with the command "show all rows" (in german: alle Zeilen anzeigen) I 
wanted to delete one row and selected it with the mouse and after that 
clicked the delete-icon. After a table-refresh all rows had been deleted 
and I had to restore the table from our backup. I tried the same 
behaviour in pgadmin 1.40 and it worked without a problem. So for me 
pgadmin 1.61 behaves as if the table has no primary-key assigned when 
the primary-key column is not the first column of the table and can not 
build the where-statement for the delete-command properly. Has somebody 
else seen this behaviour?

Thanks
Oliver


    
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Oliver Baden wrote:
> Hi!
> 
> I have a table where the primary key is a serial but the position of the
> primary key is not the first column. Today when showing all recordsets
> with the command "show all rows" (in german: alle Zeilen anzeigen) I
> wanted to delete one row and selected it with the mouse and after that
> clicked the delete-icon. After a table-refresh all rows had been deleted
> and I had to restore the table from our backup. I tried the same
> behaviour in pgadmin 1.40 and it worked without a problem. So for me
> pgadmin 1.61 behaves as if the table has no primary-key assigned when
> the primary-key column is not the first column of the table and can not
> build the where-statement for the delete-command properly. Has somebody
> else seen this behaviour?

I'm sorry that you've lost data :-(

I've been testing this with a copy of pg_class, in which I used
relfilenode as a primary key and couldn't reproduce the problem. I then
changed the primary key to be relfilenode and relisshared
(non-consecutive columns, neither of which are at the beginning or end)
and that worked as expected as well.

Can you still reproduce the problem (on a test database of course!). If
so, can you share the table definition please?

Thanks, Dave.