From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Increase value of OUTER_VAR |
Date: | 2021-09-11 17:42:06 |
Message-ID: | 99323.1631382126@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> writes:
> But why the Index type still uses for indexing of range table entries?
> For example:
> - we give int resultRelation value to create_modifytable_path() as Index
> nominalRelation value.
> - exec_rt_fetch(Index) calls list_nth(int).
> - generate_subquery_vars() accepts an 'Index varno' value
As I mentioned, the patch only intends to touch code that's possibly
used with post-setrefs Vars. In the parser and most of the planner,
there's little need to do anything because only positive varno values
will appear. So touching that code would just make the patch more
invasive without accomplishing much.
If we'd had any strong convention about whether RT indexes should be
int or Index, I might be worried about maintaining consistency.
But it's always been a horrid mishmash of both ways. Cleaning that
up completely is a task I don't care to undertake right now.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2021-09-11 18:03:57 | new regexp_*(text, text, int) functions crash |
Previous Message | Tom Lane | 2021-09-11 17:37:47 | Re: Increase value of OUTER_VAR |