Re: Help with DELETE statement via ODBC
От | Carlos Abalde |
---|---|
Тема | Re: Help with DELETE statement via ODBC |
Дата | |
Msg-id | 20040607201341.GA5962@lfcia.org обсуждение исходный текст |
Ответ на | Re: Help with DELETE statement via ODBC (Håkon Clausen <hakonhc@nospam.hclausen.net>) |
Ответы |
Re: Help with DELETE statement via ODBC
|
Список | pgsql-odbc |
Håkon Clausen wrote... > Hi Carlos, > > This is the correct behavior. Deleting 0 rows will give an ODBC error. > You will have to rewrite your query so that this does not occur. Hi Håkon, I'm not an expert on ODBC and maybe this is and philosophical discussion, buy I think that DELETE querys are very usual in DB applications, and querys like, DELETE FROM table WHERE field = foreign_key that are very common when you are working with 1-N relations, need a normal behaviour when 0 rows are deleted. For example, +---------+ 1 N +-----------+ | Formula |----------------| Parameter | +---------+ +-----------+ for_key par_key for_txt par_for (foreign key) ... par_nam par_val ... Represents a formula with several parameters. If we have a new list of parameters for a existing formula, the best way to update then is to delete the old parameters and create the new ones. With the current DELETE behaviour, the normal case of a formula without parameters must be considered as a special case! I think that there is a lot of examples like this in DB aplications. Moreover, as DBs are highly related with Set Theory, it's an error the current behaviour, because the empty set is dealed as a special case. These are the mains reasons I think the current behaviour is erroneus. However, as I said before, maybe this is a philosophical discussion :). Best regards, +---.---.---.---.---.---.---.---.---+---.---.---.---.---.---.---.---+ | Carlos Abalde (carlos@lfcia.org) | http://www.lfcia.org/~carlos | + LFCIA Lab, Dept. Computer Science | +34.981.167000 ext. 1275 + | University of A Coruna, Spain | PGP Key ID = 0x04DF0EAF | +-.---.---.---.---.---.---.---.---.-+-.---.---.---.---.---.---.---.-+
В списке pgsql-odbc по дате отправления: