Andres Freund <andres@anarazel.de> writes:
> On 2019-08-15 10:09:14 -0700, Peter Geoghegan wrote:
>> On Thu, Aug 15, 2019 at 10:05 AM Andres Freund <andres@anarazel.de> wrote:
>>> Seems like it's more a question of preventing the hook from resolving things at that point?
>> I don't know.
> Seems like we'd just need a new EXPR_KIND_*, maybe
> EXPR_KIND_ARBITER_EXPRESSION, which plpgsql's column hook would just
> ignore.
It's already using EXPR_KIND_INDEX_EXPRESSION, so I doubt you need a
new exprkind; it'd be fine not to resolve plpgsql variables in CREATE
INDEX too. Possibly the same could happen for some other exprkinds.
But I'm not really sure that having the hook discriminate against
particular exprkinds is a good idea, on two grounds:
1. It introduces user-visible inconsistency. Despite the OP's opinion,
I am not convinced that having "id" behave differently here than it
would elsewhere is a good thing.
2. It seems like an inevitable source of future bugs, when somebody
changes something in a way that makes it desirable to resolve plpgsql
variables in a particular exprkind. Yeah, that most likely means they
should have split that exprkind in two, but this is the sort of action
at a distance that's very unlikely to get noticed until too late.
Maybe it'd be a net positive despite these objections, but I do not
think it's a clear-cut win.
regards, tom lane