Re: [BUGS] BUG #13126: table constraint loses its comment
От | Michael Paquier |
---|---|
Тема | Re: [BUGS] BUG #13126: table constraint loses its comment |
Дата | |
Msg-id | CAB7nPqShiFo2pDCs_tRzcDZGbKT4tbC3kfOoijKAo40ZQD=E-A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #13126: table constraint loses its comment (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: [BUGS] BUG #13126: table constraint loses its comment
|
Список | pgsql-hackers |
On Tue, Jul 14, 2015 at 1:42 AM, Heikki Linnakangas wrote: > There was one bug in this patch: the COMMENT statement that was constructed > didn't schema-qualify the relation, so if the ALTERed table was not in > search_path, the operation would fail with a "relation not found" error (or > add the comment to wrong object). Fixed that. Ouch. I had a look at the patches and they look neater than what I drafted. Thanks! > I plan to commit the attached patches later today or tomorrow. But how do > you feel about back-patching this? It should be possible to backpatch, > although at a quick test it seems that there have been small changes to the > affected code in many versions, so it would require some work. Also, in > back-branches we'd need to put the new AT_ReAddComment type to the end of > the list, like we've done when we added AT_ReAddConstraint in 9.3. I'm > inclined to backpatch this to 9.5 only, even though this is clearly a bug > fix, on the grounds that it's not a very serious bug and there's always some > risk in backpatching. Well, while it's clearly a bug I don't think that it is worth the risk to destabilize back branches older than 9.5 in this code path. So +1 for doing it the way you are suggesting. We could still revisit that later on if there are more complaints, but I doubt there will be much. -- Michael
В списке pgsql-hackers по дате отправления: