From: | Scott Marlowe <smarlowe(at)g2switchworks(dot)com> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Chad <chadzakary(at)hotmail(dot)com>, pgsql general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: How do I use the backend APIs |
Date: | 2006-02-20 22:44:48 |
Message-ID: | 1140475488.5777.1.camel@state.g2switchworks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, 2006-02-20 at 16:40, Martijn van Oosterhout wrote:
> On Mon, Feb 20, 2006 at 05:08:33AM -0800, Chad wrote:
> > 4. Why I think I need to work at this level of abstraction. I believe,
> > certain types of queries can be realized more efficiently by code that
> > can seek to specific parts of an index and immediately returning a
> > small number of rows to the client. The query would remain active and
> > the client would only retrieve the next rows after the previous cursor
> > position when the client was ready to do so. With a huge underlying
>
> <snip>
>
> You realise you can acheive almost exactly what you want here by saying
> things like:
>
> DECLARE c AS CURSOR FOR select * from table where name >= 'Mal' order by name;
> FETCH FORWARD 1; -- Go down
> FETCH FORWARD 1; -- Go down
> FETCH BACKWARD 2; -- Go back again
>
> If you have an index it will just step through the index to find the
> rows you want. While you're free to try and make this work by using the
> index code directly, you're not asking anything that's otherwise
> impossible.
I think the problem here is that when you have a hammer, everything
looks like a nail. We see it with people coming from Oracle or DB2 as
well. "I learned it this way" is often a bigger obstacle to learning
postgresql than no knowledge at all.
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2006-02-20 23:11:33 | Re: Mixing different LC_COLLATE and database encodings |
Previous Message | Martijn van Oosterhout | 2006-02-20 22:40:21 | Re: How do I use the backend APIs |