Re: selecting large result sets in psql using cursors
От | Chris Mair |
---|---|
Тема | Re: selecting large result sets in psql using cursors |
Дата | |
Msg-id | 1155827896.3948.16.camel@dell.home.lan обсуждение исходный текст |
Ответ на | Re: selecting large result sets in psql using cursors (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] selecting large result sets in psql using
Re: [HACKERS] selecting large result sets in psql using |
Список | pgsql-patches |
Hi, thanks for reviewing this :) > > attached is the new and fixed version of the patch for selecting > > large result sets from psql using cursors. > > The is_select_command bit is wrong because it doesn't allow for left > parentheses in front of the SELECT keyword (something entirely > reasonable when considering big union/intersect/except trees). > Also you'd need to allow for VALUES as the first keyword. You're right, I improved is_select_command to take these into account. (Btw, I didn't even know a command VALUES existed..) > But isn't the whole thing unnecessary? ISTM you could just ship the > query with the DECLARE CURSOR prepended, and see whether you get a > syntax error or not. I find it neat that \u gives a good error message if someone executes a non-select query. If I leave that out there is no way to tell a real syntax error from one cause by executing non-selects... Anyway, if we don't want the extra check, I can skip the is_select_command call, of course. Patch with fix against current CVS is attached. > At some point we ought to extend libpq enough to expose the V3-protocol > feature that allows partial fetches from portals; that would be a > cleaner way to implement this feature. However since nobody has yet > proposed a good API for this in libpq, I don't object to implementing > \u with DECLARE CURSOR for now. > > BTW, \u seems not to have any mnemonic value whatsoever ... isn't there > some other name we could use? True :) Since buffer commands all have a single char I wanted a single char one too. The "c" for "cursor" was taken already, so i choose the "u" (second char in "cursor"). If somebody has a better suggestion, let us know ;) Bye, Chris. PS: I'm traveling Fri 18th - Fri 25th and won't check mail often. -- Chris Mair http://www.1006.org
Вложения
В списке pgsql-patches по дате отправления: