Problem with parser - Mailing list pgsql-hackers

From jwieck@debis.com (Jan Wieck)
Subject Problem with parser
Date
Msg-id m0z7NIH-000EBPC@orion.SAPserv.Hamburg.dsh.de
Whole thread Raw
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
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;

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

pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Dropping partial index support - Dont!
Next
From: Linda Chow
Date:
Subject: access Postgre database through JDBC driver from Netscape FastTrack3.0.1 machine