Re: Something's busted in plpgsql composite-variable handling
Вложения
В списке pgsql-hackers по дате отправления:
| От | Jonathan S. Katz |
|---|---|
| Тема | Re: Something's busted in plpgsql composite-variable handling |
| Дата | |
| Msg-id | FD595754-A473-4AFD-972A-BF906C300236@postgresql.org обсуждение |
| Ответ на | Re: Something's busted in plpgsql composite-variable handling (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Something's busted in plpgsql composite-variable handling
|
| Список | pgsql-hackers |
> On Aug 26, 2018, at 4:09 PM, Tom Lane <tgl@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. Jonathan
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера