From: | Jan Wieck <janwieck(at)yahoo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jan Wieck <janwieck(at)yahoo(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Jessica Perry Hekman <jphekman(at)dynamicdiagrams(dot)com>, Barry Lind <barry(at)xythos(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: timeout implementation issues |
Date: | 2002-04-05 18:53:56 |
Message-ID: | 200204051853.g35IruV09704@saturn.janwieck.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Jan Wieck <janwieck(at)yahoo(dot)com> writes:
> > Could we get out of this by defining that "timeout" is
> > automatically reset at next statement end?
>
> I was hoping to avoid that, because it seems like a wart. OTOH,
> it'd be less of a wart than the global changes of semantics that
> Bruce is proposing :-(
>
> How exactly would you make this happen? The simplest way I can think of
> to do it (reset timeout in outer loop in postgres.c) would not work,
> because it'd reset the timeout as soon as the SET statement completes.
> How would you get the setting to survive for exactly one additional
> statement?
I would vote for a general callback registering mechanism,
where you can specify an event, a function and an opaque
pointer. Possible events then would be end of statement, end
of transaction, commit, abort, regular end of session.
Sure, it looks like total overkill for this minor JDBC
problem. But I like general support structures to be in
place early.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #
From | Date | Subject | |
---|---|---|---|
Next Message | Dann Corbit | 2002-04-05 19:04:13 | Suggestion for optimization |
Previous Message | Tom Lane | 2002-04-05 18:40:52 | Re: PQescapeBytea is not multibyte aware |