Обсуждение: Advice needed,

Hi all,

I've been trying to implement UPDATE and DELETE to work on subclasses.

I made some changes and it kinda seems to work. It works when I have no
WHERE condition. When I put a WHERE condition in, it seems to update the
wrong tuple, and then things go wierd...

pghack=# update a set aa='zzz' where oid=19286;
UPDATE 1
pghack=# select oid,* from a; oid  |  aa  
-------+------19286 | aaaa19285 | zzz
(2 rows)

pghack=# update a set aa='zzz' where oid=19285;
ERROR:  heap_update: (am)invalid tid
ERROR:  heap_update: (am)invalid tid
pghack=# update a set aa='zzz';
ERROR:  heap_update: (am)invalid tid
ERROR:  heap_update: (am)invalid tid

This message seems to be something to do with a tuple being in an
"Invisible" state whatever that means.

The change I made was basicly to add an "inh" parameter to
setTargetTable which I pass on down to addRangeTableEntry. From there I
expect it to be passed on to the executor and as I said it seems to work
ok without a where clause.

The patch is here. Any suggestions on where to start looking?

ftp://ftp.tech.com.au/pub/patch.only2






-- 
Chris Bitmead
mailto:chris@bitmead.com

> I've been trying to implement UPDATE and DELETE to work on subclasses.
> The change I made was basicly to add an "inh" parameter to
> setTargetTable which I pass on down to addRangeTableEntry. From there I
> expect it to be passed on to the executor and as I said it seems to work
> ok without a where clause.

Hi Chris. I don't have time to look at you patches right now, since
I'm trying to get some syntax stuff finished up and committed. But fyi
my patches touch addRangeTableEntry and other files in the parser, so
you'll likely have a bit of a merge effort to get these sync'd back
up. Sorry :(
                    - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California

Chris <chris@bitmead.com> writes:
> I've been trying to implement UPDATE and DELETE to work on subclasses.

Good!

> The change I made was basicly to add an "inh" parameter to
> setTargetTable which I pass on down to addRangeTableEntry. From there I
> expect it to be passed on to the executor and as I said it seems to work
> ok without a where clause.

Hm.  I do not believe that the executor is currently prepared to cope
with more than one target table for an UPDATE or DELETE.  You'll
probably need to do some work in execMain.c and related files.  Not
sure why it seemed to work at all...
        regards, tom lane

Tom Lane wrote:
> > The change I made was basicly to add an "inh" parameter to
> > setTargetTable which I pass on down to addRangeTableEntry. From there I
> > expect it to be passed on to the executor and as I said it seems to work
> > ok without a where clause.
> 
> Hm.  I do not believe that the executor is currently prepared to cope
> with more than one target table for an UPDATE or DELETE.  You'll
> probably need to do some work in execMain.c and related files.  Not
> sure why it seemed to work at all...

Been doing more tracing. The flow of code seems to be going the way one
might
expect.

Here is the strange thing. If I have
CREATE TABLE a (aa text);
CREATE TABLE b (bb text) inherits (a);

If I have a WHERE clause that updates at least one tuple in both a AND
b.

For example...
SELECT oid,* from ONLY a;
1234 | abcd
SELECT oid,* from ONLY b;
5678 | defg | NULL

Now if I have...
UPDATE a SET aa='zzzz' WHERE oid=1234 or oid=5678 
it works ok. or...
UPDATE a SET aa='zzzz';
it works ok.
But if I have a WHERE clause that only touches "a" table or only touches
"b"
table, it just updates the wrong stuff, but appears to work. From then
on
it doesn't work at all. 

Is there any function to print out a tuple?? I'm not sure how to do this
in the
debugger. Why can't pprint do it?