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, older
discussion and art
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 suppose. Some SQL engin
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
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 connection-local, it makes
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 sti
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?
>>
>
> Yes
>
>
>> Yes, prepared s
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
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 complet
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 persis
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,
you
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 pe
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 co
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 f
13 matches
Mail list logo