Re: [HACKERS] [NOVICE] Why is there a doubtful copyObject call in add_vars_to_targetlist - Mailing list pgsql-hackers

From David Rowley
Subject Re: [HACKERS] [NOVICE] Why is there a doubtful copyObject call in add_vars_to_targetlist
Date
Msg-id CAKJS1f9T49A1nazCoYcaJG51fJEK3fbSqW+Y=5MnBkRr91z-kg@mail.gmail.com
Whole thread Raw
Responses Re: [HACKERS] [NOVICE] Why is there a doubtful copyObject call in add_vars_to_targetlist  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
(Redirecting to Hackers, since Novice is not the correct place for this question)

On 13 March 2017 at 14:22, Neha Khatri <nehakhatri5@gmail.com> wrote:
Hi,

I was debugging that when does the function _copyVar get invoked, and the first hit for that was in the add_vars_to_targetlist. There I happened to see the following comment:

/* XXX is copyObject necessary here? */

Further digging showed that this copyObject got added in the commit 5efe3121: 

+       /* XXX is copyObject necessary here? */
+ rel->targetlist = lappend(rel->targetlist,
+                           create_tl_element((Var *) copyObject(var),
+                                             length(rel->targetlist) + 1));

This copyObject still exits in the current code. So I was wondering if the comment question still holds good and why the question there in first place.
To make a new Var object, copyObject seem to be the right choice, then why the doubt?

The doubt is in the fact if copyObject() is required at all. The other option being to simply reference the same object without having made a copy.

The danger of not making a copy would be that any changes made would naturally affect all things which reference the object. It would seem the comment and the copyObject() are still there because nobody is satisfied that it's not required enough to go and remove it, that weighted against the fact that removing likely wouldn't buy that much performance wise is likely the reason it's still there.

Probably if someone came up with a realistic enough case to prove that it was worth removing, then someone might take some time to go and check if it was safe to remove. There's a good chance that it'll not happen until then, giving that nobody's bothered in almost 18 years.


--
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
Next
From: Andreas Karlsson
Date:
Subject: Re: [HACKERS] REINDEX CONCURRENTLY 2.0