Re: [BUGFIX] amcanbackward is not checked before building backward index paths

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> To make matters worse, IIUC it's actually fine to read the cursor in one
> direction to completion, then in the other direction to completion,
> without this flag, right?

In principle that'd be possible without amcanbackward if you were to
shut down the plan at the end of the forward scan and start a fresh
execution for the backwards scan; but there is no code or API for doing
that with a cursor. So I think this is just a red herring.

The case that's actually of interest is where you write

SELECT ... FROM tab ORDER BY indexed_col DESC

and then just read that normally without a cursor, or at least without
a scrollable one. This does not require amcanbackward, since the
executor will not change scan directions: it's all ForwardScanDirection
at the top level (which gets inverted to BackwardScanDirection somewhere
in nodeIndexscan, which knows the index is being used backwards).

Currently we assume that any index capable of amcanorder can do this
scenario too. I'm willing to entertain a proposal to have a separate
capability flag for it, although I think it's fair to question whether
designing an order-supporting index AM that can't do this is actually a
good idea. The current user docs say explicitly that you don't need
to make both ASC and DESC order indexes on the same thing. I do not
really want to put in weasel wording saying "unless you're using some
crappy third party index type".

regards, tom lane