On Fri, Jun 5, 2026 at 7:55 PM Amjad Shahzad <amjadshahzad2000@gmail.com> wrote:
>
> Hi Fujii,
>
> You are correct. I checked the libpq source and both PQconsumeInput() and PQnotifies() have explicit NULL guards:
>
> /* fe-exec.c line 2003 */
> if (!conn)
> return 0;
>
> /* fe-exec.c line 2688 */
> if (!conn)
> return NULL;
>
> So no segmentation fault actually occurs. The function silently returns 0 rows when called without a prior connection
insteadof crashing.
>
> The real issue is a behavioral inconsistency: every other dblink function that uses the default connection explicitly
checksfor NULL
> and calls dblink_conn_not_avail() to give a clear error message.
>
> dblink_get_notify() is the only exception, it silently returns an empty result set, which could mislead callers into
thinkingno
> notifications exist when in fact no connection was established.
dblink_get_notify() was introduced by commit f4095b4c4b2 in 2009,
and it appears to have behaved this way ever since. So there may be
existing systems that depend on the current behavior. Also, there do not
seem to have been any complaints about it over the past 10+ years.
Therefore, unless the current behavior can be shown to cause actual
issues or risks, I'm just feeling tempted to avoid changing it...
At the very least, I don't think we should change the behavior in
the back branches. Thought?
Regards,
--
Fujii Masao