Andrew Gierth <and...@tao11.riddles.org.uk> writes:
> This obviously happens because plpgsql is storing the variable as an
> expanded list of fields rather than as a single composite datum, and
> rebuilding the datum value when it needs to be passed to SQL for
> evaluation. Without an "isnull" flag for each composite subvalue, this
> can't regenerate the original datum closely enough to give the same
> value on an isnull test.
> What to do about this?
Sooner or later, I think we're going to have to bite the bullet and
switch over to using regular composite datums for plpgsql composite
variables --- that is, use the REC not ROW code paths for that case.
The ROW code paths should only get used for cases like "SELECT INTO a,b,c"
--- where there's no way to name the row-as-a-whole so no question
arises of whether it's null or not.
People have pushed back on that idea for various reasons, but we're
never going to have consistent behavior at this level of detail
until we do it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
