From: | Erwin Moller <erwinmoller(at)xs4all(dot)nl> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: psql reports back wrong number of affected rows. |
Date: | 2011-06-17 14:16:27 |
Message-ID: | 4DFB61BB.2010507@xs4all.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 6/14/2011 8:08 PM, David Johnston wrote:
>> alter table tblissue add constraint
>> "tblissue_parentissueid_fkey_casc_del" FOREIGN KEY (parentissueid)
>> REFERENCES tblissue(issueid) ON DELETE CASCADE;
>> =============================================
>>
>> Then:
>> delete from tblissue where issueid=1;
>> DELETE 1
>>
>> Postgresql now deletes all rows that had a 1 for parentissueid. (5 in my
>> testcase).
>> That was correct, and as I intended, but why does Postgres answer "DELETE
>> 1" instead of DELETE 6?
>>
>> Can somebody explain that to me please?
>> Thanks for your time.
> You only explicitly deleted a single row; all the rest were done via the
> CASCADE and thus are not counted in the delete count.
>
> Make sense; If I delete a record and see "DELETE 1000" because 999 FK
> records were deleted I would have no way of know if I foo-barred the DELETE
> query itself and actually killed 1000 records using the DELETE itself or got
> it right and hit the 1 intended record and simply got 999 more deletions
> indirectly.
>
> I can see where a more helpful response would be: "DELETE 1 \n NOTICE: 999
> FK references were deleted due to Cascade" but the "DELETE 1" MUST show me
> explicitly how many records were deleted solely due to my DELETE statement's
> FROM and WHERE clauses.
Agree 100%.
I am not a big fan of CASCADING effects (I rather do it 'by hand'), but
in this case it was a really easy solution.
Thanks you for your response.
Regards,
Erwin Moller
> David J.
>
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Thom Brown | 2011-06-17 14:22:33 | Re: [HACKERS] Issues with generate_series using integer boundaries |
Previous Message | Kevin Grittner | 2011-06-17 13:55:22 | Re: Postgres 8.3.10 Alter Table Waiting issue |