Re: [RFC] How about changing the default value of defaultRowFetchSize?

From: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
To: 'Dave Cramer' <pg(at)fastcrypt(dot)com>
Cc: Jorge Solórzano <jorsol(at)gmail(dot)com>, "Vitalii Tymchyshyn" <vit(at)tym(dot)im>, Mark Rotteveel <mark(at)lawinegevaar(dot)nl>, List <pgsql-jdbc(at)postgresql(dot)org>, Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>
Subject: Re: [RFC] How about changing the default value of defaultRowFetchSize?
Date: 2016-10-26 02:02:29
Message-ID: 0A3221C70F24FB45833433255569204D1F63681D@G01JPEXMBYT05
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

From: davecramer(at)gmail(dot)com [mailto:davecramer(at)gmail(dot)com] On Behalf Of
> Dave Cramer
> This states that if setFetchSize has not been called then we return what
> we want. Given that if the statement is in auto-commit then the fetch size
> is irrelevant. The correct logic would be if autocommit=false then return
> the default value, otherwise 0, but I'm not advocating this either.
>
> So my question to you is how would you use this information anyway? It's
> not like you can allocate more memory or something to accommodate the rows.
> It makes more sense to me that if I get 0 back then I know I have to set
> it. If I get the value back that I set it to then I know what's going on.
> I would assert that anyone that is knowledgable enough to use this is going
> to call setFetchSize.

I got your point, thanks. I agree that getFetchSize() returns 0 when setFetchSize() hasn't been called yet or setFetchSize(0) was called. Users can interpret the return value of 0 as (1) defaultRowFetchSize if autocommit is off, or (2) all rows if autocommit is on.

I think I'll submit a patch. Of course, I don't mind if anyone will do it.

Regards
Takayuki Tsunakawa

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Brad DeJong 2016-10-26 12:17:11 Re: setCharacterStream(int, Reader)
Previous Message Greg Stark 2016-10-25 18:50:37 Re: postgresql support new time zone TRT