Message-Id: <200211080211.gA82BQDq214174@pimout3-ext.prodigy.net>
Content-Type: text/plain;
  charset="iso-8859-1"
From: elein <elein@sbcglobal.net>
Reply-To: elein@norcov.com
To: Neil Conway <neilc@samurai.com>, josh@agliodbs.com
Subject: Re: Cannot assign ROWTYPE, RECORD variables in PL/pgSQL
Date: Thu, 7 Nov 2002 19:11:29 -0800
Cc: <pgsql-bugs@postgresql.org>, elein@norcov.com
References: <6BD8CE460CC6EE40B83DDFCED609F84B964D55@cmnt4008.rvc.ac.uk>
	<200211061427.16554.josh@agliodbs.com>
	<87u1itcacs.fsf@mailbox.samurai.com>
In-Reply-To: <87u1itcacs.fsf@mailbox.samurai.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable


Deep copy with User defined data types sometimes get a little=20
wild, possibly with alignment and memory context.  For example=20
a UDT which is a char followed by an int might be tricky to recognize
that alignment might be needed.  It might even be better to  have=20
the UDT writer write their own deep copy function if their type=20
is not compatible with a straight memcpy.

One of the other reasons this was a real PITB at informix was that=20
columns could also contain row (composite) types.  We do not=20
have that feature (yet?), but if deep copy is done in a type=20
blind way which is open to adding recursion we would not shut=20
the door on the possibility.  Tables have rows which have columns
containing rows which have columns containing udts and rows....

However, I suspect that postgresql row handling is a lot cleaner than
the informix row handling (with or without rows as columns) and it=20
has been a while since I looked at the problem so maybe it is a=20
non-issue.  But I'm raising it just in case...

elein


On Thursday 07 November 2002 13:56, Neil Conway wrote:
> Josh Berkus <josh@agliodbs.com> writes:
> > create or replace function rowtype_test ()
> > returns text as '
> > declare this_row candidates%rowtype;
> > 	that_row candidates%rowtype;
> > begin
> > select * into this_row
> > from candidates;
> >
> > that_row :=3D this_row;
> >
> > return that_row.first_name;
> >
> > end;'
> > language 'plpgsql';
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >
> > ... it will error out at the assignment "that_row :=3D this_row".
>
> So we'd want a deep copy, right?
>
> > The only way to populate that_row with a copy of this_row is by
> > re-querying the source table.
>
> Well, you can also iterate through the fields of this_row and assign
> them to that_row manually -- of course, that's not much better.
>
> > While a relatively easy workaround, this behaviour is annoying and
> > inconsistent.  It would be nice to fix in 7.3.1 or 7.4.
>
> Unless anyone sees a problem with this, I'll work on this. I
> definately think it's inappropriate for 7.3.1 though.
>
> Cheers,
>
> Neil