Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL
Date
Msg-id 1276679.1677626421@sss.pgh.pa.us
Whole thread Raw
In response to Refactoring SysCacheGetAttr to know when attr cannot be NULL  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers
Daniel Gustafsson <daniel@yesql.se> writes:
> The attached refactoring introduce SysCacheGetAttrNotNull as a wrapper around
> SysCacheGetAttr where a NULL value triggers an elog().

+1, seems like a good idea.  (I didn't review the patch details.)

> This will reduce granularity of error messages, and as the patch sits now it
> does so a lot since the message is left to work on - I wanted to see if this
> was at all seen as a net positive before spending time on that part.  I chose
> an elog since I as a user would prefer to hit an elog instead of a silent keep
> going with an assert, this is of course debateable.

I'd venture that the Assert cases are mostly from laziness, and
that once we centralize this it's plenty worthwhile to generate
a decent elog message.  You ought to be able to look up the
table and column name from the info that is at hand.

Also ... at least in assert-enabled builds, maybe we could check that
the column being fetched this way is actually marked attnotnull?
That would help to catch misuse.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Marking options deprecated in help output
Next
From: Jacob Champion
Date:
Subject: Re: [PoC] Let libpq reject unexpected authentication requests