Re: Proposal for prepared statements API

2014-04-02 Thread Ramiro Morales
On Thu, Mar 27, 2014 at 5:11 AM, VernonCole wrote: > There was a recent query about prepared statements on the db-sig mailing > list, too. Apparently thought is being given to adding such functionality to > Psycopg. This thread on the psycopg mailing list (and the linked,

Re: Proposal for prepared statements API

2014-03-27 Thread Curtis Maloney
On 27 March 2014 19:11, VernonCole wrote: > There was a recent query about prepared statements on the db-sig mailing > list, too. Apparently thought is being given to adding such functionality > to Psycopg. If such functionality is added, it could be useful to support, > I

Re: Proposal for prepared statements API

2014-03-27 Thread VernonCole
There was a recent query about prepared statements on the db-sig mailing list, too. Apparently thought is being given to adding such functionality to Psycopg. If such functionality is added, it could be useful to support, I suppose. Some SQL engines apparently benefit from the techinque. MS SQL

Re: Proposal for prepared statements API

2014-03-26 Thread Aymeric Augustin
2014-03-26 9:16 GMT+01:00 Anssi Kääriäinen : > We can do this by having a map of SQL for the statement -> name of the > prepared statement in the connection. On connection close the known > statements are cleaned. Yes, that seems correct. Since prepared statements are

Re: Proposal for prepared statements API

2014-03-26 Thread Anssi Kääriäinen
On 03/26/2014 06:06 AM, Curtis Maloney wrote: Further, as an "expert" feature, would it be unreasonable to limit its use to cases where you know it will benefit, but also only be used in a single connection? True, this limits its use cases somewhat, but it's

Re: Proposal for prepared statements API

2014-03-25 Thread Curtis Maloney
On 26 March 2014 10:10, Florian Apolloner wrote: > On Tuesday, March 25, 2014 11:57:51 PM UTC+1, Curtis Maloney wrote: >> >> Firstly -- can we assume anyone using this feature is not a complete >> novice, and so will take the caveats mentioned into consideration? >> > >

Re: Proposal for prepared statements API

2014-03-25 Thread Florian Apolloner
On Tuesday, March 25, 2014 11:57:51 PM UTC+1, Curtis Maloney wrote: > > Firstly -- can we assume anyone using this feature is not a complete > novice, and so will take the caveats mentioned into consideration? > Yes > Yes, prepared statements are local to their connection/session. And would

Re: Proposal for prepared statements API

2014-03-25 Thread Curtis Maloney
Firstly, I mostly proposed this API in response to others calls for it. Yes, I'd love to have it, but I'm content to leave it in the "too hard" basket. That said, it doesn't mean I'm not going to try to solve these issue :) So: Firstly -- can we assume anyone using this feature is not a

Re: Proposal for prepared statements API

2014-03-25 Thread Shai Berger
On IRC, @apollo13 asked some very good questions about the lifecycle of prepared statements. I would like to elaborate. Prepared statements usually live on the server, in the context of a session -- which, for Django, means they're only valid in the thread where they were built; without

Re: Proposal for prepared statements API

2014-03-25 Thread Jeremy Dunck
On the None -> IS NULL issue, I presume there are, for any given use case, not that many argument permutations of None and not None passed. I suggest that the PreparedStatement abstraction map to multiple actual prepared statements, one for each None/not None permutation. Then when executing,

Re: Proposal for prepared statements API

2014-03-25 Thread Michael Manfre
Is falling back to a direct queries being considered? Not all backends support prepared statements or recommend using them. The native mssql drivers support prepared statements, but the other drivers django-mssql supports do not. Also, "In SQL Server, the prepare/execute model has no significant

Re: Proposal for prepared statements API

2014-03-25 Thread Anssi Kääriäinen
On Tuesday, March 25, 2014 2:53:42 PM UTC+2, Curtis Maloney wrote: > > ps = MyModel.objects.filter(foo__lt=Param('a').prepare() > > The result is now a callable that accepts one parameter - "a". To invoke > the query: > > results = ps(a=1000) > > > Clearly it's early days yet - I've written no

Proposal for prepared statements API

2014-03-25 Thread Curtis Maloney
I've been discussing this idea for some time now, and was reminded of it recently... and akaariai has pushed me to put forward this proposal. Prepared Statements. The benefit of prepared statements, for those who don't know, is it avoids repeating the time the Query Planner in the DBMS takes to