From: Tom Lane <tgl@sss.pgh.pa.us>
To: pm91.arapov@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18848: DEREF_AFTER_NULL.EX.COND After having been compared
 to a NULL
In-reply-to: <18848-62f448851e967b5c@postgresql.org>
References: <18848-62f448851e967b5c@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Fri, 14 Mar 2025 09:12:41 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3055349.1741962427.1@sss.pgh.pa.us>
Date: Fri, 14 Mar 2025 10:27:07 -0400
Message-ID: <3055350.1741962427@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3055350.1741962427%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> Looks like there is inconsistency with 'ind_name' and 'int_type' checks. In
> one place both are checked. In other place only the second one is checked.
> It's possible that when the second is not NULL the first is also not NULL.
> If this is so then the problem is not real. But it's hard to prove this. In
> any case the code needs to be made more clear.

Perhaps it needs to be made more clear, but this patch seems like no
improvement.  Adding that Assert accomplishes nothing --- the code
will dump core if ind_name is null, with or without an Assert.

Given the lack of field complaints, I'm inclined to believe there's
not a bug here.

			regards, tom lane