On Wed, 2 Dec 2020 at 12:20, Daniele Varrazzo <daniele.varra...@gmail.com> wrote:
> One little change I've made to psycopg3 cursors is to make it return > "self" on execute() (it currently returns None, so it's totally > unused). This allows chaining a fetch operation right after execute, > so the pattern above can be reduced to: > > conn = psycopg3.connect(dsn) > cur = conn.cursor() > record = cur.execute(query, params).fetchone() > # or > for record in cur.execute(query, params): > ... # do something > 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 > > 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). > > 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? I like it a lot! Ciao. Marco.
