Re: Prepared statements considered harmful
От | Andrew Dunstan |
---|---|
Тема | Re: Prepared statements considered harmful |
Дата | |
Msg-id | 44F72780.5020001@dunslane.net обсуждение исходный текст |
Ответ на | Re: Prepared statements considered harmful (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: Prepared statements considered harmful
|
Список | pgsql-hackers |
Martijn van Oosterhout wrote: > On Thu, Aug 31, 2006 at 06:43:38PM +0100, Gregory Stark wrote: > >> Peter Eisentraut <peter_e@gmx.net> writes: >> >>> - Redefine "prepared" to mean "parsed" rather than "parsed and planned". >>> >> Then you would be going very much against the user's expectations. >> >> Driver interfaces expose very clearly to the user an explicit interface to >> prepare and execute a query separately. What your proposing is to go behind >> the user's back and do what he's gone out of his way to tell you not to do. >> You can always choose to prepare your queries immediately before use. Most >> drivers even supply an interface to do so in a single step for convenience. >> > > Is that really so? Under Perl DBI, the only way to get a statement > handle is to "prepare" it. Yet I don't want to use server-side prepares > because I know of the problems it causes. The "single-step" approach > provides no statement handle at all, which has several drawbacks. > > People are encouraged to use prepared stataments for clarity and > security reasons, not speed. I would really like an option to choose > between: > > - slightly more planning time but always good plans > - plan once and be unforgiving if the plan doesn't work with the > parameters > > I'd take the first option anyday, but that's just the types of queries > I'm doing. > > Have a nice day, > According to the docs you can actually choose between server side prepare or not on a per call basis. It contains this example: $sth->{pg_server_prepare} = 1; $sth->execute(22); $sth->{pg_server_prepare} = 0; $sth->execute(44); $sth->{pg_server_prepare} = 1; $sth->execute(66); cheers andrew
В списке pgsql-hackers по дате отправления: