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

From: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Something's busted in plpgsql composite-variable handling
Date: 2018-08-28 14:38:06
Message-ID: FD595754-A473-4AFD-972A-BF906C300236@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> 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.

Jonathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chapman Flack 2018-08-28 14:40:43 Re: typcache.c typos
Previous Message Mariel Cherkassky 2018-08-28 14:36:05 Catalog corruption