From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Dean Gibson (DB Administrator)" <postgresql@ultimeth.com>
cc: pgsql-sql@postgresql.org
Subject: Re: NULLs and composite types
In-reply-to: <52AA3156.20902@ultimeth.com>
References: <52A9010D.3070202@ultimeth.com>
 <1386876331115-5783187.post@n5.nabble.com> <52AA3156.20902@ultimeth.com>
Comments: In-reply-to "Dean Gibson (DB Administrator)"
 <postgresql@ultimeth.com>
 message dated "Thu, 12 Dec 2013 13:57:42 -0800"
Date: Thu, 12 Dec 2013 18:57:34 -0500
Message-ID: <3726.1386892654@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-sql-owner@postgresql.org

"Dean Gibson (DB Administrator)" <postgresql@ultimeth.com> writes:
> However, my problem is not that the comparison tests produce different 
> results;  that's just a symptom.  My problem is that PostgreSQL is 
> *changing* a NULL record value, to a record with NULLs for the component 
> values, when I attempt to INSERT or UPDATE it into a different field.  

I don't think there is any mechanism in core Postgres that would do that.

plpgsql, however, is a different story.  It has two different methods for
representing composite-type variables, and only one of those is capable of
representing a a "simple NULL" record value.  So I suspect what is
happening is that one of your plpgsql trigger functions is doing something
with the location field that causes it to become a row-of-nulls.  You've
not shown us enough detail to pinpoint the problem though.

			regards, tom lane


-- 
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql