Re: binary protocol, again
От | Daniele Varrazzo |
---|---|
Тема | Re: binary protocol, again |
Дата | |
Msg-id | CA+mi_8ZBzWDjiX1PQnrXrTVSUtp6pCTfvyq2ytjDU=Q-5PmrNA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: binary protocol, again ("P. Christeas" <xrg@linux.gr>) |
Ответы |
Re: binary protocol, again
|
Список | psycopg |
On Fri, Jul 20, 2012 at 6:34 PM, P. Christeas <xrg@linux.gr> wrote: > On Friday 20 July 2012, you wrote: >> On Fri, Jul 20, 2012 at 6:09 PM, P. Christeas <xrg@linux.gr> wrote: >> >> 3. using PQexecParams instead PQexec >> > >> > Yes, when query is eligible. >> >> Uhm... what is an eligible query? > One that is single (not multi with semicolons), and NOT a "COMMENT" or > "EXECUTE" one. You should be hunting for semicolons in the query with knowledge of comments (single line, multiline, nested), strings (including dollar-quoted strings, unicode-escape, standard-conforming)... It seems a painful road. >> Are you changing the behaviour of the current cursor class or >> introducing a new one? I'd go most definitely for the second, as I'm >> afraid the first would break a lot of the existing usage. > Introducing a new one "cursor_bin", as we've discussed before. Great :) Sorry though, I haven't got it: have you decided introducing now the cursor_bin, hence you don't need parsing the query to see if it's eligible or were you already using the cursor_bin? In the latter case, why are you parsing the query and not always using PQexecParams? >> In particular, what I'd like to see is a protocol ISQLParam, to live >> together with the current ISQLQuote, in order to create a clear >> distinction between the capabilities of the two cursors and avoid >> bloating the current adapters interface. > > Hmm. I named it "BSQLQuote", but I guess "ISQLParam is a much better name. > I'll change that. Lovely (not bikeshedding about the name: the important is the protocols to be distinct) Thank you again -- Daniele
В списке psycopg по дате отправления: