On Mon, 20 Feb 2006, Tom Lane wrote:
> "Sergey E. Koposov" <math@sai.msu.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.
>
Now, I understand the problem... But I would rather insist on my submitted
patch. Because, after applying my patch the problem exists only in one
session (the query does not work only in the same backend where the column
was dropped, but in any next sessions it works perfectly), but without a
patch it just does not work at all (in any next sessions)(surprisingly
even after vacuum full of the table).
And I would say that the patch is rather logical, it does not look like a
hack, so it's worth applying it (on my opinion).
Regards,Sergey
*****************************************************
Sergey E. Koposov
Max Planck Institute for Astronomy
Web: http://lnfm1.sai.msu.ru/~math
E-mail: math@sai.msu.ru