Thanks for the note on the bugfix in the update. I will try it. However, there is no naming conflict. The idea was this:
The select query should return one result row for each row in the FROM clause since there is no WHERE clause. Each result row should be the contents of the complex1 data type contained by mydatasource. That set of resulting rows should be converted to an array and assigned to myvariable. On Fri, Jun 4, 2010 at 11:23 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Alban Hertroys <dal...@solfertje.student.utwente.nl> writes: > > I'm pretty sure you have a naming conflict. > > Yeah. Specifically, the given example looks like it would try to assign > a null to the target variable, since it'd be taking the null value of a > different variable instead of a value from the intended source. > > I believe the bizarre error message is coming from a plpgsql bug that we > fixed in 8.4.3, which basically was that assigning a null to a composite > variable would fail in some cases. If you weren't shooting yourself in > the foot with naming conflicts, you might not trip over that case ... > but an update to 8.4.recent wouldn't be a bad idea anyway. > > regards, tom lane > -- Eliot Gable "We do not inherit the Earth from our ancestors: we borrow it from our children." ~David Brower "I decided the words were too conservative for me. We're not borrowing from our children, we're stealing from them--and it's not even considered to be a crime." ~David Brower "Esse oportet ut vivas, non vivere ut edas." (Thou shouldst eat to live; not live to eat.) ~Marcus Tullius Cicero