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

On 8/28/18 12:06 PM, Pavel Stehule wrote:
>
>
> 2018-08-28 17:04 GMT+02:00 Jonathan S. Katz <jkatz(at)postgresql(dot)org
> <mailto:jkatz(at)postgresql(dot)org>>:
>
>
>> On Aug 28, 2018, at 10:45 AM, Pavel Stehule
>> <pavel(dot)stehule(at)gmail(dot)com <mailto:pavel(dot)stehule(at)gmail(dot)com>> wrote:
>>
>>
>>
>> 2018-08-28 16:38 GMT+02:00 Jonathan S. Katz <jkatz(at)postgresql(dot)org
>> <mailto:jkatz(at)postgresql(dot)org>>:
>>
>>
>> > On Aug 26, 2018, at 4:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us
>> <mailto: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?
>
> 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

I've gone ahead and moved this to "Live Issues" - Thanks!

Jonathan