Problem with parser

From: jwieck(at)debis(dot)com (Jan Wieck)
To: pgsql-hackers(at)postgreSQL(dot)org (PostgreSQL HACKERS)
Subject: Problem with parser
Date: 1998-08-14 17:05:36
Message-ID: m0z7NIH-000EBPC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)debis(dot)com (Jan Wieck) #

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Linda Chow 1998-08-14 18:54:12 access Postgre database through JDBC driver from Netscape FastTrack3.0.1 machine
Previous Message Hannu Krosing 1998-08-14 16:09:44 Re: Dropping partial index support - Dont!