Michael Glaesemann <grzm@seespotcode.net> writes:
> On Oct 12, 2010, at 12:53 , Josh Kupershmidt wrote:
>> SELECT (CASE WHEN attname IS NULL THEN true ELSE false END) AS
>> 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
accurate:
>>> 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
