On Fri, Apr 05, 2002 at 11:19:04AM -0500, Tom Lane wrote:
> Jan Wieck <janwieck@yahoo.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?
How about not messing with the SET, but adding it to the SELECT syntax
itself? a "WITH TIMEOUT" clause?
This is the first of the (proposed) SET variables that affects query
performance that is not a 'twiddle with the internals because something
is really wrong' hack (or debugging tool, if you will) Argueably,
those also suffer from the punching through the transaction problem:
I'd certainly hate (for example) to have sequential scans disabled for
an entire connection because one gnarly query that the optimizer guesses
wrong on died, and my reset got ignored. I'd hate it, but understand
that it's a crufty hack to get around a problem, and just deal with
resetting the transaction/connection.
Timeouts, on the other hand, are a much more respectable mainline sort
of extension, apparently required for certain standards (The JDBC people
started this discussion, right?). They should be fully supported by the
transactional machinery, however that is decided. If that means all
SETs become transactional, I don't really see a problem with that.
Or, as I suggested above, extend the SELECT (and other querys?) syntax
seems reasonable. More so than the non-standard 'use this index, really'
types of extensions that other RDBMSs provide, that we've rightly avoided.
Thoughts?
Ross
