From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: troubleshooting pointers |
Date: | 2002-05-11 14:57:53 |
Message-ID: | 12690.1021129073@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Joe Conway <mail(at)joeconway(dot)com> writes:
> Tom Lane wrote:
>> It's not unlikely that those issues are exactly due to not having rescan
>> handled properly. What misbehavior are you seeing?
> Hmm, that might just be it.
> When I select from a view based on a function which returns a base type,
> I only get the first row. When I select from a view which is based on a
> function returning a composite type, it triggers an assertion. I've
> traced the latter down to a slot pointer which is reset to NULL
> somewhere.
Um, that's probably not it then. Rescan would only come into play for
a plan node that's being used as the inside of a join, or some other
contexts more complicated than this. A simple view ought to make no
difference at all in the generated plan --- perhaps there's some bit
of the planner that you missed teaching about function RTEs or
FunctionScan plan nodes?
Anyway, I plan to review and apply your patch today, if I don't run
into any major problems. Will look to see if I see a reason for the
view trouble.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-05-11 15:15:02 | Re: internal voting |
Previous Message | Bartus Levente | 2002-05-11 12:36:17 | Re: internal voting |
From | Date | Subject | |
---|---|---|---|
Next Message | Ian Barwick | 2002-05-11 16:01:46 | Re: Set Returning Functions (SRF) - request for patch review and comment |
Previous Message | Rod Taylor | 2002-05-11 14:40:14 | Re: pg_depend patch |