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
