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

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Something's busted in plpgsql composite-variable handling
Date: 2018-08-28 16:06:42
Message-ID: CAFj8pRD8SFu+RTXOMZLOaX9ZEHw28qMPn1ZArYP8VuaThp0Stg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

>
> On Aug 28, 2018, at 10:45 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
>
>
>
> 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?
>
>
> 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
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Erik Rijkers 2018-08-28 16:33:38 Re: FETCH FIRST clause PERCENT option
Previous Message Alexander Korotkov 2018-08-28 15:50:31 Re: Reopen logfile on SIGHUP