>
> Yes you are wrong. As I and others have already answered you tables are
> unordered sets of rows. There is no position. Postion comes to play on
> your
> client side when you see your data in some nice grid

Ok.
So, how does first/skip works?

2007/8/17, sasha <selectnull@...>:

>
> >
> > >
> > > There is no "position" in a table, there's only a "position" in a
> > > resultset that's ordered.
> >
> > Ok. So i'll rewrite my question:
> > Is it possible to select some records from a resultset based
> > on their positions?
> > I think it's the same idea used by the first/skip clauses. Am I wrong?
> >
> Yes you are wrong. As I and others have already answered you tables are
> unordered sets of rows. There is no position. Postion comes to play on
> your
> client side when you see your data in some nice grid and think, ah this
> record comes after the other one so it must be that they have positions in
> tables. A couple of years of studying relational theory and you might see
> why that kind of thinking is wrong.
>
> But, I am sure that you want some results and not blabing about
> relations...
> So here is something for you...
>
> create table p(
> id integer);
> commit;
> insert into p(id) values (1);
> insert into p(id) values (2);
> insert into p(id) values (4);
> insert into p(id) values (5);
> insert into p(id) values (8);
> insert into p(id) values (10);
> insert into p(id) values (15);
> insert into p(id) values (19);
> insert into p(id) values (30);
> commit;
>
> select p.id, count(*)
> from p
> join p p2 on p2.id <= p.id
> group by p.id
> having count(*) in (1, 2, 4)
>
> this query selected 1st, 2nd and 4th row... Isn't that what you wanted?
> Do it on a set of more than couple of hundreds of rows and your server
> will
> hate you, but i'll leave it you to understand why... :)
>
> Sasha
>
>
>

[Non-text portions of this message have been removed]