Lists: | pgsql-novice |
---|
From: | Noel Faux <Noel(dot)Faux(at)med(dot)monash(dot)edu(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Noel <noel(dot)faux(at)med(dot)monash(dot)edu(dot)au>, pgsql-novice(at)postgresql(dot)org |
Subject: | Re: problem with using fetch and a join. |
Date: | 2002-12-21 23:50:11 |
Message-ID: | 5aa1745aa9ec.5aa9ec5aa174@mail1.monash.edu.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-novice |
Tom,
Many thanks for the tip. Yes adding the order by (id) to the statement
allowed the FETCH BACKWARD to work. Is there any reason why the FETCH
BACKWARD statement for such a join not to be supported in the future?
Once again,
Many Thanks
And have a great holiday season :D
Noel Faux
Department of Biochemistry and Molecluar Biology
Monash University
Clayton 3168
Victoria
Australia
----- Original Message -----
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Saturday, December 21, 2002 1:47 am
Subject: Re: [NOVICE] problem with using fetch and a join.
> Noel <noel(dot)faux(at)med(dot)monash(dot)edu(dot)au> writes:
> > begin;
> > declare test cursor for
> > select protein.accession
> > from protein, region
> > where protein.accession like '%1245%'
> > and protein.accession = region.accession
> > and region.protein_database = 1;
> > fetch forward 2 in test;
> > fetch backward 1 in test;
>
> FETCH (or MOVE) BACKWARD doesn't work with most join plan types (or
> indeed anything much more complex than a simple seqscan or indexscan).
> There ought to be some logic in there to detect and complain about the
> non-working cases, but right now I fear you just get the wrong answer
> when any given routine doesn't pay attention to the direction flag
> :-(
>
> I believe it will work when the top plan node is a Sort, so one
> possibleworkaround is to add an explicit ORDER BY to the query.
>
> regards, tom lane
>
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Noel Faux <Noel(dot)Faux(at)med(dot)monash(dot)edu(dot)au> |
Cc: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: problem with using fetch and a join. |
Date: | 2002-12-22 04:42:43 |
Message-ID: | 22946.1040532163@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-novice |
Noel Faux <Noel(dot)Faux(at)med(dot)monash(dot)edu(dot)au> writes:
> Many thanks for the tip. Yes adding the order by (id) to the statement
> allowed the FETCH BACKWARD to work. Is there any reason why the FETCH
> BACKWARD statement for such a join not to be supported in the future?
If someone wants to make it happen ... my take is that actually making
it work in all cases would be lots more trouble than it's worth. I'd
settle for producing an error message in place of a wrong answer.
regards, tom lane
From: | Noel <noel(dot)faux(at)med(dot)monash(dot)edu(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: problem with using fetch and a join. |
Date: | 2003-01-15 01:11:51 |
Message-ID: | 3E24B557.1090303@med.monash.edu.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-novice |
Hi Tom,
I'm also having problems with fecthing and moving backwards within a view.
ie. (comparison_region_protein is a view)
int result = stmt.executeUpdate("declare test cursor for select id from " +
"comparison_region_protein where db_db_comparison =
1 order by id");
I can move and fetch forward, but i can't fetch or move backwards. Is
this because of the reasons metioned before? Is there a work around?
Many thanks
Noel
Tom Lane wrote:
>Noel Faux <Noel(dot)Faux(at)med(dot)monash(dot)edu(dot)au> writes:
>
>
>>Many thanks for the tip. Yes adding the order by (id) to the statement
>>allowed the FETCH BACKWARD to work. Is there any reason why the FETCH
>>BACKWARD statement for such a join not to be supported in the future?
>>
>>
>
>If someone wants to make it happen ... my take is that actually making
>it work in all cases would be lots more trouble than it's worth. I'd
>settle for producing an error message in place of a wrong answer.
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>