Re: dropped columns, tupDesc

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Sergey E(dot) Koposov" <math(at)sai(dot)msu(dot)ru>
Cc: pgsql-hackers(at)postgresql(dot)org, Neil Conway <neilc(at)samurai(dot)com>
Subject: Re: dropped columns, tupDesc
Date: 2006-02-20 22:57:04
Message-ID: 29363.1140476224@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Sergey E. Koposov" <math(at)sai(dot)msu(dot)ru> writes:
> I've recently proposed a patch
> http://archives.postgresql.org/pgsql-patches/2006-02/msg00165.php
> to fix an old problem with dropped columns, but recently
> http://archives.postgresql.org/pgsql-patches/2006-02/msg00246.php
> Neil Conway have discovered the problem even with the patch. After looking
> on the problem it seems that my patch just discovered an additional set of
> incosistencies of Postgres in the work with droppped columns.

> I looked in the source of those problems and it seems that I have found
> it, but it is situated rather deep in Postgres and I don't have enough
> expertise too judge it. So I would be interested if someone clarify the
> issue for me and how the problem should be fixed.

This is not really fixable without some infrastructure to flush cached
plans when the things they depend on change. That's a system-wide
problem and it'd be a mistake to spend much time hacking localized
stopgaps.

Neil has been making noises about working on the real problem, but I dunno
how far along he is.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-02-20 23:20:00 Re: SPI: Correct way to rollback a subtransaction?
Previous Message Peter Eisentraut 2006-02-20 22:08:24 Re: Generating config stuff from single source