Re: Something's busted in plpgsql composite-variable handling

2018-08-28 16:38 GMT+02:00 Jonathan S. Katz <jkatz(at)postgresql(dot)org>:

>
> > On Aug 26, 2018, at 4:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
>
>