Re: Executing on the connection?
От | Rory Campbell-Lange |
---|---|
Тема | Re: Executing on the connection? |
Дата | |
Msg-id | 20201202124807.GA21315@campbell-lange.net обсуждение исходный текст |
Ответ на | Executing on the connection? (Daniele Varrazzo <daniele.varrazzo@gmail.com>) |
Ответы |
Re: Executing on the connection?
|
Список | psycopg |
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
В списке psycopg по дате отправления: