Re: SQL injection
От | Martijn van Oosterhout |
---|---|
Тема | Re: SQL injection |
Дата | |
Msg-id | 20051101220022.GE21137@svana.org обсуждение исходный текст |
Ответ на | Re: SQL injection (Yonatan Ben-Nes <da@canaan.co.il>) |
Ответы |
Re: SQL injection
|
Список | pgsql-general |
On Tue, Nov 01, 2005 at 11:31:36PM +0200, Yonatan Ben-Nes wrote: > And about the performance penalty, I don't really care about losing the > benefit of prepared statements, I'm actually more afraid of receiving > penalty of using them... the following is quoted from the manual: > "In some situations, the query plan produced for a prepared statement > will be inferior to the query plan that would have been chosen if the > statement had been submitted and executed normally. This is because when <snip> Note: Just because your coding style uses prepared statements doesn't mean it uses them in the server. For example, in Perl DBI it has that whole prepare/execute cycle, but the values are actually interpolated (with appropriate quoting) on the client side and sent as a normal query. Hence have your cake and eat it too... Now, in theory a newer DBI version could use server side prepared statements but I imagine I'll be turning them off. I don't have any queries with a significant parse/plan cost to make it worth the costs you mention here... It's a pity the protocol doesn't have a single shot prepare/bind command which would allow you to send the values out-of-line (no quoting issues) but still provide them at the planning/optimising stage to get good plans. Ah well, can't have everything. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
Вложения
В списке pgsql-general по дате отправления: