Re: In Postgres 16 BETA, should the ParseNamespaceItem have the same index as it's RangeTableEntry? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: In Postgres 16 BETA, should the ParseNamespaceItem have the same index as it's RangeTableEntry?
Date
Msg-id 3173476.1689286373@sss.pgh.pa.us
Whole thread Raw
In response to In Postgres 16 BETA, should the ParseNamespaceItem have the same index as it's RangeTableEntry?  (Farias de Oliveira <matheusfarias519@gmail.com>)
Responses Re: In Postgres 16 BETA, should the ParseNamespaceItem have the same index as it's RangeTableEntry?
List pgsql-hackers
Farias de Oliveira <matheusfarias519@gmail.com> writes:
> With further inspection in AGE's code, after executing the SET query,
> it goes inside transform_cypher_clause_as_subquery() function and the
> ParseNamespaceItem has the following values:

>  {p_names = 0x1205638, p_rte = 0x11edb70, p_rtindex = 1, p_perminfo =
> 0x7f7f7f7f7f7f7f7f,
>   p_nscolumns = 0x1205848, p_rel_visible = true, p_cols_visible =
> true, p_lateral_only = false,
>   p_lateral_ok = true}

Hmm, that uninitialized value for p_perminfo is pretty suspicious.
I see that transformFromClauseItem and buildNSItemFromLists both
create ParseNamespaceItems without bothering to fill p_perminfo,
while buildNSItemFromTupleDesc fills it per the caller and
addRangeTableEntryForJoin always sets it to NULL.  I think we
ought to make the first two set it to NULL as well, because
uninitialized fields are invariably a bad idea (even though the
lack of valgrind complaints says that the core code is managing
to avoid touching those fields).

If we do that, is it sufficient to resolve your problem?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Allowing parallel-safe initplans
Next
From: Jeff Davis
Date:
Subject: Re: Fix search_path for all maintenance commands