On Fri, Jan 04, 2019 at 05:43:12PM +0100, Christoph Zwerschke wrote: > Am 03.01.2019 um 22:52 schrieb Justin Pryzby:> One thought ; should "name" > be an kwarg with default name='' ? > > It's now implemented that way. But I noticed an issue with unnamed queries. > It seems like Postgres replaces the unnamed query as soon as it's running > any other query. That means any query that the DB wrapper is running behind > the scenes (e.g. to fetch types) or you are running in your code between > query_prepared() calls will destroy the unnamed query. > > So this makes unnamed query really not that useful and we should discourage > using them. The question is then, should we not revert that change and use a > positional argument for the name again. That's more convenient than a > keyword-only argument if you need to set it anyway every time.
Good catch. I'm not opposed to requiring "name" if that's where things lead.. But instead should pygres use NAMED prepared statements for its internal queries, to avoid its unnamed queries conflicting with users' unnamed prepared statements ? Currently it calls PQexecParams which (I think you agree) is creating unnamed prepared statements behind the scenes. I see that in the CSV logs, every query is logged as either a "statement: ..." for simple queries with PQexec, or "<unnamed>: ..." for PQexecParams. postgres has something called a portal, which might also allow working around that, but it kind of looks like you'd need to implement an custom interface rather than using libpq, which is a non-starter. Note that internal queries were also an issue when I was working on server side cursors (I'm not referring to "cursor interface" / pseudo-cursors). I forget the details right now but it's what made me stop thinking about server cursors at least until the interface was ironed out. Thanks, Justin _______________________________________________ PyGreSQL mailing list [email protected] https://mail.vex.net/mailman/listinfo/pygresql
