Thread: Re: [HACKERS] Support for JDBC setQueryTimeout, et al.

Re: [HACKERS] Support for JDBC setQueryTimeout, et al.

From
"Kevin Grittner"
Date:
Robert Haas  wrote:
Kevin Grittner  wrote:

> I thought we had decided on the client-side approach, but maybe
> I'm confused. I don't have a position one way or the other, just
> trying to understand the state of the conversation.

Well, I've been pretty vocal on supporting a client-side solution,
and Rados*aw clearly is in that camp, but that hardly makes a
consensus.  David still has his patch out there, and Tom's comments
seemed to imply that he supports a solution involving the
statement_timeout GUC, so the question hardly seems settled.

Regarding JDBC in the CF process -- other interfaces are handled
there.  I haven't seen one patch this size for JDBC since I've been
involved, let alone two competing patches to implement the same
feature.  Small patches which can be quickly handled don't make sense
to put into the process, but it seemed reasonable for these.

-Kevin

Re: [HACKERS] Support for JDBC setQueryTimeout, et al.

From
Radosław Smogura
Date:
> Regarding JDBC in the CF process -- other interfaces are handled
> there.  I haven't seen one patch this size for JDBC since I've been
> involved, let alone two competing patches to implement the same
> feature.  Small patches which can be quickly handled don't make sense
> to put into the process, but it seemed reasonable for these.

In any way I'm sending this patch, and I will put this under Miscellaneous in
CF. This cleared patch takes only 47k (in uncleared was some binary read
classes) and about 50% it's big test case.

Have a nice day,
Radek

Attachment

Re: [HACKERS] Support for JDBC setQueryTimeout, et al.

From
Tom Lane
Date:
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Robert Haas  wrote:
>> I thought we had decided on the client-side approach, but maybe
>> I'm confused. I don't have a position one way or the other, just
>> trying to understand the state of the conversation.

> Well, I've been pretty vocal on supporting a client-side solution,
> and Rados*aw clearly is in that camp, but that hardly makes a
> consensus.  David still has his patch out there, and Tom's comments
> seemed to imply that he supports a solution involving the
> statement_timeout GUC, so the question hardly seems settled.

No, no, I was trying to point out some reasons why depending on
statement_timeout would be problematic.  I'm all for doing this
client-side.

            regards, tom lane

Re: [HACKERS] Support for JDBC setQueryTimeout, et al.

From
Itagaki Takahiro
Date:
On Fri, Oct 15, 2010 at 03:40, Radosław Smogura
<rsmogura@softperience.eu> wrote:
>> Regarding JDBC in the CF process -- other interfaces are handled
>> there.  I haven't seen one patch this size for JDBC since I've been
>> involved, let alone two competing patches to implement the same
>> feature.  Small patches which can be quickly handled don't make sense
>> to put into the process, but it seemed reasonable for these.
>
> In any way I'm sending this patch, and I will put this under Miscellaneous in
> CF. This cleared patch takes only 47k (in uncleared was some binary read
> classes) and about 50% it's big test case.

I changed the patch's topic to "JDBC".
https://commitfest.postgresql.org/action/patch_view?id=399

Patch reviewers are still wanted.

--
Itagaki Takahiro

Re: [HACKERS] Support for JDBC setQueryTimeout, et al.

From
Kris Jurka
Date:

On Mon, 22 Nov 2010, Itagaki Takahiro wrote:

> On Fri, Oct 15, 2010 at 03:40, Rados?aw Smogura
> <rsmogura@softperience.eu> wrote:
>>> Regarding JDBC in the CF process -- other interfaces are handled
>>> there.  I haven't seen one patch this size for JDBC since I've been
>>> involved, let alone two competing patches to implement the same
>>> feature.  Small patches which can be quickly handled don't make sense
>>> to put into the process, but it seemed reasonable for these.
>>
>> In any way I'm sending this patch, and I will put this under Miscellaneous in
>> CF. This cleared patch takes only 47k (in uncleared was some binary read
>> classes) and about 50% it's big test case.
>
> I changed the patch's topic to "JDBC".
> https://commitfest.postgresql.org/action/patch_view?id=399
>

I don't think it makes sense to try to manage anything other than core
code in the commitfest app.  The other patch touched the backend, so it
made sense to put it in the commitfest, but as far as I understand it,
this one is pure Java code.  There is a backlog of JDBC issues to deal
with, but I think it needs its own commitfest instead of trying to tack on
to the main project's.

Kris Jurka

Re: [HACKERS] Support for JDBC setQueryTimeout, et al.

From
Robert Haas
Date:
On Tue, Nov 23, 2010 at 2:33 AM, Kris Jurka <books@ejurka.com> wrote:
>
>
> On Mon, 22 Nov 2010, Itagaki Takahiro wrote:
>
>> On Fri, Oct 15, 2010 at 03:40, Rados?aw Smogura
>> <rsmogura@softperience.eu> wrote:
>>>>
>>>> Regarding JDBC in the CF process -- other interfaces are handled
>>>> there.  I haven't seen one patch this size for JDBC since I've been
>>>> involved, let alone two competing patches to implement the same
>>>> feature.  Small patches which can be quickly handled don't make sense
>>>> to put into the process, but it seemed reasonable for these.
>>>
>>> In any way I'm sending this patch, and I will put this under
>>> Miscellaneous in
>>> CF. This cleared patch takes only 47k (in uncleared was some binary read
>>> classes) and about 50% it's big test case.
>>
>> I changed the patch's topic to "JDBC".
>> https://commitfest.postgresql.org/action/patch_view?id=399
>>
>
> I don't think it makes sense to try to manage anything other than core code
> in the commitfest app.  The other patch touched the backend, so it made
> sense to put it in the commitfest, but as far as I understand it, this one
> is pure Java code.  There is a backlog of JDBC issues to deal with, but I
> think it needs its own commitfest instead of trying to tack on to the main
> project's.

We could have separate JDBC CommitFests inside the app if that's
helpful - the CommitFests are by convention named YYYY-MM, but the app
will support arbitrary names.  The only problem I see is that it would
mess up the calculation of "the currently open CF" and "the currently
in progress CF" and "the most recently closed CF".  I'd be willing to
put in the work to fix that, though, if you guys want to use the app
too.

For now I suggest we mark this Returned with Feedback.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company