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

From jwieck@debis.com (Jan Wieck)
Subject Re: [HACKERS] Problem with parser
Date
Msg-id m0z7See-000EBPC@orion.SAPserv.Hamburg.dsh.de
Whole thread Raw
In response to Re: [HACKERS] Problem with parser  (Bruce Momjian <maillist@candle.pha.pa.us>)
Responses Re: [HACKERS] Problem with parser  (Bruce Momjian <maillist@candle.pha.pa.us>)
Re: [HACKERS] Problem with parser  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers
> 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?
>
> --
> Bruce Momjian                          |  830 Blythe Avenue

    Right!  The  rewrite  code  assumes  that the resdomno of the
    updated columns match the  attribute  number  in  the  target
    relation.   I  don't  know if the join is messing it up - but
    looks like.  Thanks for the help - I think I have to look for
    usage  of  p_last_resno to find all the places where this can
    happen.

    Little joke:

    At the place in analyze.c, where a TLE is created, there is a
    comment  that  not creating a proper target list with correct
    resdomno's might break rules :-)

    I love those comments. And especially  all  that  have  XXXXX
    somewhere.


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) #

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Problem with parser
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Problem with parser