Skip site navigation (1) Skip section navigation (2)

Re: NonNullValue() error in 8.4

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Glaesemann <grzm(at)seespotcode(dot)net>
Cc: Josh Kupershmidt <schmiddy(at)gmail(dot)com>, Rebecca Cooper <rebecca(dot)cooper(at)newforestnpa(dot)gov(dot)uk>, pgsql-novice(at)postgresql(dot)org
Subject: Re: NonNullValue() error in 8.4
Date: 2010-10-12 19:20:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-novice
Michael Glaesemann <grzm(at)seespotcode(dot)net> writes:
> On Oct 12, 2010, at 12:53 , Josh Kupershmidt wrote:
>> has_oid FROM pg_attribute;

> Or just "SELECT attname IS NULL AS has_oid"

Actually I believe nonnullvalue(x) means x IS NOT NULL.  It was never
documented because you were always supposed to use that SQL-standard
syntax instead.  Before about 7.2, the parser converted IS NOT NULL
to nonnullvalue(), but it was only meant as an implementation detail.

But there is a bigger issue here, if Rebecca's quote from her logfile is

>>> SELECT NonNullValue(attname) AS has_oid FROM pg_attribute

namely, what the heck the client-side code thinks it's doing with that.
pg_attribute.attname is not null by definition, so this query appears to
reduce to constant TRUE --- and whether it's true or not doesn't seem to
have anything to do with whether the attribute has an OID, because table
attributes don't have their own OIDs, and have not had them since PG 7.1.
So that AS label is really making me wonder what is going on here.
I am thinking this code is left over from ancient history and was
already badly patched at least once.  I'd advise looking into what is
really needed according to the client logic rather than just papering
over the observable symptom.

			regards, tom lane

In response to

pgsql-novice by date

Next:From: Mladen GogalaDate: 2010-10-12 20:21:02
Subject: Concurrency
Previous:From: Michael GlaesemannDate: 2010-10-12 16:57:26
Subject: Re: NonNullValue() error in 8.4

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group