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? It is not strong issue, but it is issue, that breaks without outage deployment. regards Pavel > Jonathan > >
