Subject: Re: Executing on the connection?
To: Denis Laxalde <denis.laxalde@dalibo.com>, psycopg@lists.postgresql.org
References: 
 <CA+mi_8Yc92bX3qhTqXq4LkGyn5VmQj6uRAcVebpqt398Tm4EJA@mail.gmail.com>
 <CA+mi_8Y+fuzZcT+boRwcQKPd58B=bc324MA2=TAd6xuAvfuMmw@mail.gmail.com>
 <7171e07d-bb96-dfc6-47e9-351d85f4a973@dalibo.com>
From: Adrian Klaver <adrian.klaver@aklaver.com>
Message-ID: <7e10dc93-dd36-6494-9d7a-6cad3cecacdb@aklaver.com>
Date: Tue, 8 Dec 2020 06:44:56 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <7171e07d-bb96-dfc6-47e9-351d85f4a973@dalibo.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 12/8/20 5:51 AM, Denis Laxalde wrote:
> Daniele Varrazzo a écrit :
>> On Wed, 2 Dec 2020 at 11:20, Daniele Varrazzo
>> <daniele.varrazzo@gmail.com> wrote:
>>
>>> I'm toying with the idea of adding a 'connection.execute(query,
>>> [params])' methd, which would basically just create a cursor
>>> internally, query on it, and return it. No parameter could be passed
>>> to the cursor() call, so it could only create the most standard,
>>> client-side cursor (or whatever the default for the connection is, if
>>> there is some form of cursor_factory, which hasn't been implemented in
>>> psycopg3 yet). For anything more fancy, cursor() should be called
>>> explicitly.
>>
>> This is what I've pushed earlier:
>>
>> https://www.psycopg.org/psycopg3/docs/connection.html#psycopg3.Connection.execute 
>>
>>
> 
> It did not strike me earlier, but it looks a bit weird to have 
> connection.execute() return a "cursor" to read results while this 
> "cursor" can also be used to execute commands. So, perhaps, another 
> object, with only the interface for result retrieval would be more 
> appropriate?

Why? It is no different from now where you can reuse a cursor.

> 
> Otherwise, that's a very nice addition, thanks!
> 
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com