Re: [HACKERS] Problem with parser - Mailing list pgsql-hackers

> Hi,
>
>     who's the parser guru? I need help!
>
>     I have a table t1(a int4, b int4)
>
>     When I
>
>         update t1 set b = 2 where a = 1;
>
>     I get a targetlist with 1 entry and resno=2.
>
>     But when I
>
>         update t1 set b = t2.b where a = t2.a;

Is the parser code correct here?  You are actually doing:

         update t1 set b = t2.b from t2 where a = t2.a;
                                ^^^^^^^

I don't have a running system right now because of my other patch.  Can
you send me a tree pointing to the problem?  In the above example, what
is the first resno?  EXPLAIN VERBOSE should give you the plans, and dump
detailed plans into the postmaster log file.

I think I see the problem.  In MakeTargetlistExpr(), we have this code:

    /* Processes target columns that will be receiving results */
    if (pstate->p_is_insert || pstate->p_is_update)
    {
        /*
         * insert or update query -- insert, update work only on one
         * relation, so multiple occurence of same resdomno is bogus
         */
        rd = pstate->p_target_relation;
        Assert(rd != NULL);
--->    resdomno = attnameAttNum(rd, colname);
        attrisset = attnameIsSet(rd, colname);
        attrtype = attnumTypeId(rd, resdomno);
        if ((arrayRef != NIL) && (lfirst(arrayRef) == NIL))
            attrtype = GetArrayElementType(attrtype);
        attrtypmod = rd->rd_att->attrs[resdomno - 1]->atttypmod;


This looks bad to me, especially because you have a join going on in the
update.  In fact, the comment clearly shows a false assertion, that ther
is only one relation in UPDATE.

Is the update rewrite code assuming that the resdomno of an updated
column must match the attribute number?  And the join is messing this
up?



>
>     I  get the same 1 entry targetlist with resno=1 for attribute
>     "b".  That causes deep deep trouble in  the  rewrite  system,
>     when  fixing  the  expressions for *new* variable references.
>     *new*.attr defaults to *old*.attr except given in  the  query
>     to  be  updated.  When  fixing  *new* references, the rewrite
>     system looks up the original parsetree to find a TLE with the
>     same  resno as the attribute number in the *new*.attr.  So it
>     depends on having the resno same to the attno of  the  result
>     relation.
>
>     I'm  absolutely unfamiliar with the parser in this area and I
>     don't want to hack around and break things  so  close  before
>     6.4.  Who knows how to fix this?
>
>     BTW: up to now the rewrite system looks much better. It works
>     for insert, update and delete  when  using  constant  values.
>     insert ... select ... works too.
>
>
> Jan
>
> --
>
> #======================================================================#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me.                                  #
> #======================================== jwieck@debis.com (Jan Wieck) #
>
>
>
>


--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)