Just a reminder that we could use cursors that exist after transaction
commit (WITH HOLD) and updatable cursors (WHERE CURRENT OF cursorname). :-)
---
Tom Lane wrote:
> "Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> >>
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
>> There are cases where
>> identical cursor definitions might allow or not allow backwards fetch
>> depending on the planner's choices.
> Would it be possible to give warnings in a narrow superset of the
> problematic cases, something along the li
On Sun, Mar 09, 2003 at 03:35:11PM -0500, Tom Lane wrote:
>
> 2. Error out only if a backwards fetch is actually attempted on a plan
> tree that can't handle it (which could only happen if SCROLL wasn't
> given). This is efficient and flexible, but it exposes implementation
> details to the user,
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
>> but just give a warning and then run the underlying
>> query _again_, this toime with materialize on top and also do a Move to
>> reposition the cursor. This will probably not work correctly for all
>> tranasaction isolation levels though b
>> 2. Error out only if a backwards fetch is actually attempted on a plan
>> tree that can't handle it (which could only happen if SCROLL wasn't
>> given). This is efficient and flexible, but it exposes implementation
>> details to the user, in that whether an error occurs will depend on
>> which
Tom Lane kirjutas P, 09.03.2003 kell 22:35:
> However, this is going to create backwards-compatibility issues.
> We have a few options for what to do:
>
> 1. Enforce the SQL spec requirement: error out if backwards fetch is
> done when SCROLL wasn't given. But this will surely break a lot
> of e
> > I'd be in favour of creating whole sets of backwards-compatibility GUC's
> > whenever we break backwards compatibility.
> >
> > eg.
> > use_72_compat = yes
> > use_73_compat = yes
>
> That sounds like a recipe for a maintenance nightmare to me.
We only have to keep them for one major version,
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> I'd be in favour of creating whole sets of backwards-compatibility GUC's
> whenever we break backwards compatibility.
>
> eg.
> use_72_compat = yes
> use_73_compat = yes
That sounds like a recipe for a maintenance nightmare to me.
-Doug
-
> 3. Create a runtime parameter (GUC variable) which when set causes us
> to assume SCROLL is present even if it's not stated. Setting this
> to TRUE would allow existing applications to work without modification;
> when it's FALSE, we'd enforce the spec behavior. The trouble with this
> is the T
On Sun, 2003-03-09 at 16:04, Rod Taylor wrote:
> How about a variable that turns on or off spec enforcement (case #1 or
> #2). On for 7.4, off for 7.5 the next release, and make it disappear
> after that.
Yeah, that sounds like the best solution to me.
IMHO there is a case to be made for skipping
Rod Taylor <[EMAIL PROTECTED]> writes:
> Enforcing spec seems like the least confusing mode to operate under,
> especially given it could break simply by changing the plan -- which
> happens automagically (seemingly random).
Keep in mind though that complaints about the current bugs have been
fair
> I'm presently leaning to #2, even though it exposes implementation
> details. I'm open to discussion though. Any preferences? Other ideas?
How about a variable that turns on or off spec enforcement (case #1 or
#2). On for 7.4, off for 7.5 the next release, and make it disappear
after that.
E
12 matches
Mail list logo
