On Saturday 08 April 2006 03:07, Bojan Smojver wrote:
[ Please don't Cc: me when you post to the list. One copy
of your messages is enough ]
On Fri, 2006-04-07 at 23:49 +0100, Nick Kew wrote:
It's also possible that it did exist
but that the code was written with insufficient reference to
Quoting Nick Kew [EMAIL PROTECTED]:
[ Please don't Cc: me when you post to the list. One copy
of your messages is enough ]
Ah, sorry :-(
If you want to take that on, feel free. Does it gain us anything?
Not much. Maybe a few CPU cycles that get used for building the string
PREPARE ...
On 4/6/06, Bojan Smojver [EMAIL PROTECTED] wrote:
Quoting Bojan Smojver [EMAIL PROTECTED]:
Is there are particular reason why PQprepare() isn't used to prepare
statements? Currently, DBD code builds an SQL statement with PREPARE
[...] at the beginning and then executes that, instead of
On Friday 07 April 2006 19:45, Garrett Rooney wrote:
On 4/6/06, Bojan Smojver [EMAIL PROTECTED] wrote:
Quoting Bojan Smojver [EMAIL PROTECTED]:
Is there are particular reason why PQprepare() isn't used to prepare
statements? Currently, DBD code builds an SQL statement with PREPARE
On Fri, 2006-04-07 at 23:49 +0100, Nick Kew wrote:
It's also possible that it did exist
but that the code was written with insufficient reference to TFM.
Do you know when PQprepare first appeared?
If PostgreSQL manuals are accurate (and there is no reason why they
shouldn't be), the first
Quoting Bojan Smojver [EMAIL PROTECTED]:
Is there are particular reason why PQprepare() isn't used to prepare
statements? Currently, DBD code builds an SQL statement with PREPARE
[...] at the beginning and then executes that, instead of calling the
mentioned API function.
Don't worry about
Is there are particular reason why PQprepare() isn't used to prepare
statements? Currently, DBD code builds an SQL statement with PREPARE
[...] at the beginning and then executes that, instead of calling the
mentioned API function.
--
Bojan
