Re: [HACKERS] Arrays broken on temp tables

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kristofer Munn <kmunn(at)munn(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Arrays broken on temp tables
Date: 1999-11-11 02:37:52
Message-ID: 199911110237.VAA08435@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> The problem is that the rangetable code doesn't realize that the logical
> and physical names refer to the same table, so when the
> subscript-processing code generates a reference to
> <physicaltablename>.<attribute> the parser generates a second RTE for
> the physical table name, in addition to the already-existing RTE for the
> logical table name. This causes the planner to generate a join, because
> it can see no difference between this situation and
> FROM tablename, tablename aliasname
> which *should* cause a join. But the join causes each tuple to be
> processed multiple times, which is the wrong thing for this case.
>
> There is more than one way we could attack this, but I think the
> cleanest answer will be to make it possible to extract a logical
> table name from a relcache entry.

Well, as I remember, the good news is that our code was fine, and the
original poster just missed the WHERE clause on the update. So I guess
that gets us off the hook for a while.

However, now looking at the posting again:

http://www.postgresql.org/mhonarc/pgsql-hackers/1999-11/msg00213.html

I am confused again.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-11-11 02:40:57 Re: AW: [HACKERS] Re: [GENERAL] users in Postgresql
Previous Message Tom Lane 1999-11-11 02:34:05 Re: [HACKERS] Path-length follies