Re: Obsolete comment in tidpath.c

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Obsolete comment in tidpath.c
Date: 2015-10-07 02:35:29
Message-ID: 561484F1.6050208@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015/10/07 7:01, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Oct 5, 2015 at 3:05 AM, Etsuro Fujita
>> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>>> I think "best_inner_indexscan()" in the following comment in tidpath.c
>>> is obsolete.
>>>
>>> * There is currently no special support for joins involving CTID; in
>>> * particular nothing corresponding to best_inner_indexscan(). Since it's
>>> * not very useful to store TIDs of one table in another table, there
>>> * doesn't seem to be enough use-case to justify adding a lot of code
>>> * for that.
>>>
>>> How about s/best_inner_indexscan()/parameterized scans/?
>
>> I'm not sure that's altogether clear.
>
> Probably consider_index_join_clauses() is the closest current equivalent.
> However, it may not be such a great idea to have this comment referencing
> a static function in another file, as it wouldn't occur to people to look
> here when rewriting indxpath.c. (Ahem.)
>
> Perhaps "in particular, no ability to produce parameterized paths here".

Works for me.

Best regards,
Etsuro Fujita

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2015-10-07 02:48:36 Re: Connection string parameter 'replication' in documentation
Previous Message Kouhei Kaigai 2015-10-07 00:43:12 Re: Foreign join pushdown vs EvalPlanQual