From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Dean Gibson (DB Administrator)" <postgresql(at)ultimeth(dot)com> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: NULLs and composite types |
Date: | 2013-12-12 23:57:34 |
Message-ID: | 3726.1386892654@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
"Dean Gibson (DB Administrator)" <postgresql(at)ultimeth(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Gibson (DB Administrator) | 2013-12-13 04:31:42 | Re: NULLs and composite types |
Previous Message | Dean Gibson (DB Administrator) | 2013-12-12 21:57:42 | Re: NULLs and composite types |