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 Berkus Aglio Database Solutions San Francisco ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly