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:
There
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 but it will
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, in
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 lines of I'm
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 plan the
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 TRUE
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
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, say. eg. 7.3
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
Postgres' implementation of cursors has always had a problem with doing
MOVE or FETCH backwards on complex queries. It works okay for simple
seqscans and indexscans, but fails for plans involving joins,
aggregates, and probably other cases. This happens because the executor
routines for those
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.
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
fairly
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
13 matches
Mail list logo
