Updating did solve the problem. Thanks.
On Fri, Jun 4, 2010 at 11:23 AM, Tom Lane wrote:
> Alban Hertroys 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 th
Excerpts from Eliot Gable's message of vie jun 04 16:13:28 -0400 2010:
> This is the code I posted:
>
> create type complex1 as ( ... ); -- one integer member and about 16 text
> members
> create type complex2 as ( ... ); -- few integer members, about 10 text
> members, and about 6 different enum
This is the code I posted:
create type complex1 as ( ... ); -- one integer member and about 16 text
members
create type complex2 as ( ... ); -- few integer members, about 10 text
members, and about 6 different enum members
CREATE OR REPLACE blah ...
...
DECLARE
myvariable complex1[];
mydataso
Eliot Gable writes:
> Thanks for the note on the bugfix in the update. I will try it. However,
> there is no naming conflict.
There was most certainly a naming conflict in the sample code you
posted. I realize that that probably was not the code you were
actually trying to use, but we can only g
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 co
Alban Hertroys 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 biza
On 4 Jun 2010, at 15:37, Eliot Gable wrote:
> CREATE OR REPLACE blah ...
> ...
> DECLARE
> myvariable complex1[];
> mydatasource complex1;
> myrowsource complex2[];
> ...
> BEGIN
> ...
> -- The first way I tried to do it:
> myvariable := array(
> SELECT mydatasource FROM unnest(myrow
In order to avoid using a 'FOR ... LOOP array_append(); END LOOP;' method of
building an array (which is not at all efficient), I rewrote some of my code
to do things more effectively. One of the steps involves building two arrays
that are input to another stored procedure, but I am getting an erro
