Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kkRYP-0001je-T5 for psycopg@arkaria.postgresql.org; Wed, 02 Dec 2020 12:48:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kkRYO-0001T4-JR for psycopg@arkaria.postgresql.org; Wed, 02 Dec 2020 12:48:16 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kkRYO-0001Sx-1q for psycopg@lists.postgresql.org; Wed, 02 Dec 2020 12:48:16 +0000 Received: from campbell-lange.net ([178.79.140.51]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kkRYH-00015H-MY for psycopg@postgresql.org; Wed, 02 Dec 2020 12:48:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=campbell-lange.net; s=it; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qLNgYz47/zfEgnTldt99HI9PxQyclt22ajh7HCSMMQI=; b=nyah14DDg8ySEgP+XpZUI4Edg yIbIxC2HEeGVzucaoAONcx5foozPBFAfw72a4963Tcgdz4nn7fi+QEwlRlfq/6lwb3kcq0uocGrHQ USebZP7Gj7F7fCEx/kyNgzBsedJRfNeAhBzB4B1JwmC8u0ToHXRODV9/wV9Zck1xZnfao=; Received: from [217.138.52.158] (helo=rory-t470s) by campbell-lange.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kkRYF-0001cG-Iy; Wed, 02 Dec 2020 12:48:07 +0000 Received: from rory by rory-t470s with local (Exim 4.92) (envelope-from ) id 1kkRYF-0005ik-Dt; Wed, 02 Dec 2020 12:48:07 +0000 Date: Wed, 2 Dec 2020 12:48:07 +0000 From: Rory Campbell-Lange To: Daniele Varrazzo Cc: psycopg@postgresql.org Subject: Re: Executing on the connection? Message-ID: <20201202124807.GA21315@campbell-lange.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 02/12/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. > > 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 The only issue I see with this sort of approach is the problem of having to set the search path, which I believe needs to be done for each cursor where custom search paths are used. Maybe there can be a with context to allow explicit cursor setup and teardown around an execute statement if needed, or to provide settings to the execute function. > No other methods bloating the connection interface: no executemany(), > copy(), callproc (actually there will be no callproc at all in > psycopg3: postgres has no fast path for function call and too much > semantics around stored procedure that a single callproc() couldn't > cover). Ah. We presently use callproc a lot, together with NamedTupleConnection, which works brilliantly for us. Rory