From: | elein <elein(at)sbcglobal(dot)net> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com>, josh(at)agliodbs(dot)com |
Cc: | <pgsql-bugs(at)postgresql(dot)org>, elein(at)norcov(dot)com |
Subject: | Re: Cannot assign ROWTYPE, RECORD variables in PL/pgSQL |
Date: | 2002-11-08 03:11:29 |
Message-ID: | 200211080211.gA82BQDq214174@pimout3-ext.prodigy.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-sql |
Deep copy with User defined data types sometimes get a little
wild, possibly with alignment and memory context. For example
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
the UDT writer write their own deep copy function if their type
is not compatible with a straight memcpy.
One of the other reasons this was a real PITB at informix was that
columns could also contain row (composite) types. We do not
have that feature (yet?), but if deep copy is done in a type
blind way which is open to adding recursion we would not shut
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
has been a while since I looked at the problem so maybe it is a
non-issue. But I'm raising it just in case...
elein
On Thursday 07 November 2002 13:56, Neil Conway wrote:
> Josh Berkus <josh(at)agliodbs(dot)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 := this_row;
> >
> > return that_row.first_name;
> >
> > end;'
> > language 'plpgsql';
> > =======================================
> >
> > ... it will error out at the assignment "that_row := 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
From | Date | Subject | |
---|---|---|---|
Next Message | Mats Lofkvist | 2002-11-08 15:21:14 | JDBC access broken in 7.3 beta |
Previous Message | Josh Berkus | 2002-11-07 22:57:09 | Re: Cannot assign ROWTYPE, RECORD variables in PL/pgSQL |
From | Date | Subject | |
---|---|---|---|
Next Message | Prime Ho | 2002-11-08 05:17:52 | get source table.field name from view's field |
Previous Message | Nekta Katz | 2002-11-08 00:24:12 | Re: cast lo to oid |