On Fri, Apr 05, 2002 at 11:19:04AM -0500, Tom Lane wrote: > Jan Wieck <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
