Re: Cursornames
От | Fernando Nasser |
---|---|
Тема | Re: Cursornames |
Дата | |
Msg-id | 3F2FE7B0.8050406@redhat.com обсуждение исходный текст |
Ответ на | Cursornames (Kim Ho <kho@redhat.com>) |
Список | pgsql-jdbc |
Felipe Schnack wrote: >>>I can write it today... >> >>I would appreciate if you could take the time to do it. > > Ok, I will > Thanks. > >>> Anyway, I know in the spec setFetchSize() is just a hint for the >>>driver, but the current pgsql's driver behavior isn't to create a >>>cursor? >> >>Only if it can, if it cannot it just sends the query as is and gets >>the full result set. > > When it can't? When there are multiple queries in the SQL or when you're using DECLARE I can understand... there aremore situations? Theorectically these are the two situations tested for. Maybe there is a parsing problem.. It can use a cursor when I'm not using servir-side prepared statements? > Yes, it makes a DECLARE CURSOR with your statement in it, but only if you have autocommit off (you must be in a transaction to use cursors...). > >>It is meant as a way to match the "impedance" between host languages >>which usually specify scalar variables to receive the data retrieved >>and SQL (which can return sets). > > Hm... impedance? I don't think I understand you. Maybe you can send me a private message in portuguese, as far as I rememberyou're also a Brazilian :-) Yes I could, but it would translate to "impedancia" so it would not help us much :-) What I am tryint to say is that host variables are scalar so thay can hold just one value (from one rwo), so if your query returns more than one row you must get one at a time. > But which are the situations that pgsql loads all data from the query to server's memory? I had this once, can't rememberhow I fixed it. Not sure. You would have to ask the backend folks. -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9
В списке pgsql-jdbc по дате отправления: