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


Wed, 10 Mar 2004 09:21:54 -0800
Josh Berkus <josh@agliodbs.com>
Re: [DEFAULT] Daily digest v1.4318 (23 messages)