Re: Fix pg_publication_tables to exclude generated columns
От | Amit Kapila |
---|---|
Тема | Re: Fix pg_publication_tables to exclude generated columns |
Дата | |
Msg-id | CAA4eK1LeY6vfYfFNx=b_fKfnD-m0SpkZoyqvaW82di6ywQawZQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Fix pg_publication_tables to exclude generated columns (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
RE: Fix pg_publication_tables to exclude generated columns
|
Список | pgsql-hackers |
On Wed, Jan 11, 2023 at 10:07 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Amit Kapila <amit.kapila16@gmail.com> writes: > >> On Mon, Jan 9, 2023 11:06 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > >>> We could just not fix it in the back branches. I'd argue that this is > >>> as much a definition change as a bug fix, so it doesn't really feel > >>> like something to back-patch anyway. > > > So, if we don't backpatch then it could lead to an error when it > > shouldn't have which is clearly a bug. I think we should backpatch > > this unless Tom or others are against it. > > This isn't a hill that I'm ready to die on ... but do we have any field > complaints about this? If not, I still lean against a back-patch. > I think there's a significant risk of breaking case A while fixing > case B when we change this behavior, and that's something that's > better done only in a major release. > Fair enough, but note that there is a somewhat related problem for dropped columns [1] as well. While reviewing that it occurred to me that generated columns also have a similar problem which leads to this thread (it would have been better if there is a mention of the same in the initial email). Now, as symptoms are similar, I think we shouldn't back-patch that as well, otherwise, it will appear to be partially fixed. What do you think? [1] - https://www.postgresql.org/message-id/OSZPR01MB631087C65BA81E1FEE5A60D2FDF59%40OSZPR01MB6310.jpnprd01.prod.outlook.com -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: