Re: issues with dropped columns in plpgsql code again
| От | Pavel Stehule |
|---|---|
| Тема | Re: issues with dropped columns in plpgsql code again |
| Дата | |
| Msg-id | CAFj8pRAfaNUZzVrRZAkW+d=uOT6+_AvBktJOmv4TOBYxAeg9Kw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: issues with dropped columns in plpgsql code again (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
<p dir="ltr"><br /> Dne 10.5.2013 22:17 "Tom Lane" <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>> napsal(a):<br/> ><br /> > Pavel Stehule <<a href="mailto:pavel.stehule@gmail.com">pavel.stehule@gmail.com</a>>writes:<br /> > > One user reported a issues withtriggers related to dropped columns.<br /> > > When I checked his code, I found a more possible problems.<br />><br /> > This is just the same kind of modified-rowtype problem we've discussed<br /> > before.<p dir="ltr">Yes.It is same problém. <p dir="ltr">><br /> > I continue to maintain that the only realistic fix is to stopusing the<br /> > PLPGSQL_DTYPE_ROW infrastructure for variables of externally-defined<br /> > composite types. In the last go-round, this was rejected on the<br /> > (unproven) assumption that it would make things slower. But as a wise<br /> > man once said, you can make code arbitrarily fast if it doesn't have to<br /> > givethe right answer.<p dir="ltr">Yes. It is probably solutions. <p dir="ltr">Regards<p dir="ltr">Pavel<br /> ><br />> regards, tom lane<br />
В списке pgsql-hackers по дате отправления: