Обсуждение: [HACKERS] What is the point of setrefs.c's is_converted_whole_row_reference?

AFAICS, setrefs.c's special treatment of "converted whole row references"
is completely pointless.  Why aren't they just treated by the regular
"non var" code paths, thus saving code space and cycles?
        regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, Oct 19, 2017 at 2:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> AFAICS, setrefs.c's special treatment of "converted whole row references"
> is completely pointless.  Why aren't they just treated by the regular
> "non var" code paths, thus saving code space and cycles?

Here's what one of Ashutosh's commit messages for one of the patches
in the stack said:

===
set_join_references() turns off outer side's has_non_vars to handle
expressions involving nullable side. Hence we can not use has_non_vars
to handle ConvertRowtypeExprs. Instead the patch adds
has_conv_whole_rows, which is set when there exist one or more of
ConvertRowtypeExprs described above.
===

I think that's referring to this comment:
        * Now we need to fix up the targetlist and qpqual, which are logically        * above the join.  This means
theyshould not re-use any
 
input expression        * that was computed in the nullable side of an outer join.  Vars and        * PlaceHolderVars
arefine, so we can implement this
 
restriction just by        * clearing has_non_vars in the indexed_tlist structs.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers