Обсуждение: Back-patch plpgsql fix for rowtypes with dropped columns?
I'm getting some pressure at Red Hat to back-patch this fix: http://archives.postgresql.org/pgsql-committers/2009-08/msg00068.php (commit dcb2bda9b7042dbf43f876c94ebf35d951de10e9) into the RHEL 8.4.x postgresql release. Since I have to do the work anyway, it seems to me to be sensible to commit the fix into community git as well, so that it will be available to everybody in future 8.4.x releases. 9.0 has now been out long enough that there seems no real risk of introducing new bugs, which was the reason for not back-patching at the time. The original patch modified execQual.c and some executor runtime structs to make use of the new tupconvert.c file. I'm a bit inclined to reduce the footprint of the back-patch by not touching execQual.c, but just allowing there to be some duplicated code. That would avoid any risk of breaking third-party code that might be looking at struct ConvertRowtypeExprState. I don't currently have a need to fix this before 8.4, and it looks like the existing patch doesn't apply easily to 8.3 anyway. So I'm only proposing to do this in 8.4. Comments, objections? regards, tom lane
On Thu, Apr 7, 2011 at 12:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I'm getting some pressure at Red Hat to back-patch this fix: > http://archives.postgresql.org/pgsql-committers/2009-08/msg00068.php > (commit dcb2bda9b7042dbf43f876c94ebf35d951de10e9) > into the RHEL 8.4.x postgresql release. Since I have to do the work > anyway, it seems to me to be sensible to commit the fix into community > git as well, so that it will be available to everybody in future 8.4.x > releases. 9.0 has now been out long enough that there seems no real > risk of introducing new bugs, which was the reason for not back-patching > at the time. > > The original patch modified execQual.c and some executor runtime structs > to make use of the new tupconvert.c file. I'm a bit inclined to reduce > the footprint of the back-patch by not touching execQual.c, but just > allowing there to be some duplicated code. That would avoid any risk > of breaking third-party code that might be looking at struct > ConvertRowtypeExprState. > > I don't currently have a need to fix this before 8.4, and it looks like > the existing patch doesn't apply easily to 8.3 anyway. So I'm only > proposing to do this in 8.4. > > Comments, objections? Seems reasonable. It's clearly a bug. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Hi, On Thursday 07 April 2011 18:10:35 Tom Lane wrote: > I don't currently have a need to fix this before 8.4, and it looks like > the existing patch doesn't apply easily to 8.3 anyway. So I'm only > proposing to do this in 8.4. > Comments, objections? I personally look forward to that as it has caused quite a bit of work in the field working around that problem. And I et quite a bit of calls asking what to do when that problem manifests. And all answers to that question suck. Not touching execQual.c sounds sensible. Andres