Re: EXECUTE problems
От | Felipe Schnack |
---|---|
Тема | Re: EXECUTE problems |
Дата | |
Msg-id | 1037993762.14945.67.camel@desenv1.ritterdosreis.br обсуждение исходный текст |
Ответ на | Re: EXECUTE problems (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
> > I think it should... after all, why you can use DEFAULT in an normal > > insert but you can't in an prepared insert statement? > PREPARE isn't specific to INSERT statements. Even when you use it for > one, it's not very obvious how to assign a default value to the PREPARE > parameters; in any but the most trivial cases, there's not a one-for-one > correspondence between PREPARE parameters and target columns that might > (or might not) have defaults. Well, I don't know a lot about the inner workings of pgsql (I know very little actually), but when you prepare the execution of an insert you probably have "pointers" to database metadata for all mapped columns, don't you? So if the DEFAULT keyword is found, it should fetch the default value, and raise an exception if it doesn't exist... > > I'm asking this because I'm implementing methods to support the new > > DEFAULT keyword in pgsql 7.3 for the JDBC driver... but if I can't use > > it in prepared sqls, a great deal of it usefulness will be shortened... > PREPAREing a query as trivial as an INSERT ... VALUES is largely a > waste of time anyway. So I cannot get excited about this. Well, would be a waste of time when you got this insert into a loop, etc? I don't think an SELECT statement is more adequate for "prepareing" than an insert, so (sorry) I don't get your point > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) -- Felipe Schnack Analista de Sistemas felipes@ritterdosreis.br Cel.: (51)91287530 Linux Counter #281893 Faculdade Ritter dos Reis www.ritterdosreis.br felipes@ritterdosreis.br Fone/Fax.: (51)32303328
В списке pgsql-general по дате отправления: