Subject: Re: Executing on the connection?
To: Daniele Varrazzo <daniele.varrazzo@gmail.com>, psycopg@postgresql.org
References: 
 <CA+mi_8Yc92bX3qhTqXq4LkGyn5VmQj6uRAcVebpqt398Tm4EJA@mail.gmail.com>
From: Adrian Klaver <adrian.klaver@aklaver.com>
Message-ID: <b4f9f222-fc78-1930-596b-9daf05f9d43c@aklaver.com>
Date: Wed, 2 Dec 2020 07:02:28 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: 
 <CA+mi_8Yc92bX3qhTqXq4LkGyn5VmQj6uRAcVebpqt398Tm4EJA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 12/2/20 3:20 AM, Daniele Varrazzo wrote:
> Hello,
> 

> 
> As a result people could use:
> 
>      conn = psycopg3.connect(dsn)
>      record = conn.execute(query, params).fetchone()
>      # or
>      for record in conn.execute(query, params):
>          ... # do something

That is what the sqlite3 module does and I find it handy.

> 
> No other methods bloating the connection interface: no executemany(),
> copy(), callproc (actually there will be no callproc at all in

Just to be clear the above(callproc excepted) or some variation of it 
will still be available off the cursor interface, correct?

> psycopg3: postgres has no fast path for function call and too much
> semantics around stored procedure that a single callproc() couldn't
> cover).
> 
> Being the cursor client-side, its close() doesn't actually do anythin
> apart from making it unusable, so just disposing of it without calling
> close() is totally safe.
> 
> Thoughts?
> 
> Cheers!
> 
> -- Daniele
> 
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com