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
Tom,
> Postgres' implementation of cursors has always had a problem with doing
> MOVE or FETCH backwards on complex queries.
Coincidnetally enough, I was just chatting with one of my contractors
yesterday about how the one thing that Transact-SQL has to offer is a really
good cursor implementa
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 pla
