Re: BUG #15960: ON CONFLICT Trying accessing to variables

Hi,

On 2019-08-15 18:06:25 -0400, Tom Lane wrote:
> 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.

Right.


> 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.

One counter-argument to that would be that we already don't interpret
expressions to potentially refer to plpgsql variables in some
cases. Given that those largely (all?) are DDL however, I'm not sure
it's a very strong counter argument.

CREATE OR REPLACE FUNCTION blarg() RETURNS VOID LANGUAGE plpgsql AS $$
BEGIN
    CREATE TEMPORARY TABLE blargt(id int, CHECK(id < 10));
END;$$;
SELECT blarg();

Greetings,

Andres Freund