2018-08-28 17:04 GMT+02:00 Jonathan S. Katz <jk...@postgresql.org>: > > On Aug 28, 2018, at 10:45 AM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: > > > > 2018-08-28 16:38 GMT+02:00 Jonathan S. Katz <jk...@postgresql.org>: > >> >> > On Aug 26, 2018, at 4:09 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> > >> > I wrote: >> >> [ dropping and recreating a composite type confuses plpgsql ] >> >> That's not very nice. What's worse is that it works cleanly in v10, >> >> making this a regression, no doubt caused by the hacking I did on >> >> plpgsql's handling of composite variables. >> > >> > So I'm now inclined to withdraw this as an open item. On the other >> > hand, it is a bit worrisome that I happened to hit on a case that >> > worked better before. Maybe I'm wrong to judge this unlikely to >> > happen in the field. >> > >> > Thoughts? >> >> Typically if you’re creating a composite type, you’re planning to store >> data in that type, so you’re probably not going to just drop it without >> an appropriate migration strategy around it, which would (hopefully) >> prevent the above case from happening. >> >> I wouldn’t let this block the release, so +1 for removing from open >> items. >> > > That depends - the question is - what is a reason of this issue, and how > to fix it? > > > Tom explained the cause and a proposed a fix earlier in the thread, and > cautioned that it could involve a performance hit. > > It is not strong issue, but it is issue, that breaks without outage > deployment. > > > Have you encountered this issue in the field? It is a bug, but it seems to > be an edge case based on normal usage of PostgreSQL, and I still don’t > see a reason why it needs to be fixed prior to the release of 11. If > there’s > an easier solution for solving it, yes, we could go ahead, but it sounds > like > there’s a nontrivial amount of work + testing to do. > > I do think it should be fixed for 12 now that we’ve identified it. We > could move > it from the “Open Items” to the “Live Issues” list for what it’s worth. >
+1 Regards Pavel > Jonathan >
