Chad,
> I'm talking about the stuff that the other poster (cant see his name
> right now, sorry) doubts will ever be in postgres. ie you can seek to
> anywhere in the Btree using a row offset as a "search" key.
And this is more useful than LIMIT # OFFSET # on queries, how, exactly?
> I'd love to hear why this would be hard to support in a materialized
> view. Could you explain that ? Berkeley DB supports it.
Berkeley DB is not a Relational Database.
It's not a question of "hard to support". It's a question of "don't want to
support". One of the core tenets of relational database theory is that
there are no row numbers; rows only have a fixed order as a part of a sorted
final output set (e.g. a query with an ORDER BY).
I don't know what kind of application you're trying to support that you think
row numbers are such a keen idea. As far as we're concerned, row numbers
are an inefficient throwback to the pre-relational databases of the early
1980's; why would we want them?
--
-Josh BerkusAglio Database SolutionsSan Francisco