Re: [HACKERS] [NOVICE] Why is there a doubtful copyObject call in add_vars_to_targetlist

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: [HACKERS] [NOVICE] Why is there a doubtful copyObject call in add_vars_to_targetlist
Дата
Msg-id CAKJS1f9T49A1nazCoYcaJG51fJEK3fbSqW+Y=5MnBkRr91z-kg@mail.gmail.com
обсуждение исходный текст
Ответы Re: [HACKERS] [NOVICE] Why is there a doubtful copyObject call in add_vars_to_targetlist  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
Следующее
От: Andreas Karlsson
Дата:
Сообщение: Re: [HACKERS] REINDEX CONCURRENTLY 2.0