Re: BUG #5856: pg_attribute.attinhcount is not correct.
От | Noah Misch |
---|---|
Тема | Re: BUG #5856: pg_attribute.attinhcount is not correct. |
Дата | |
Msg-id | 20110401045629.GA9314@tornado.gateway.2wire.net обсуждение исходный текст |
Ответ на | Re: BUG #5856: pg_attribute.attinhcount is not correct. (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: BUG #5856: pg_attribute.attinhcount is not correct.
|
Список | pgsql-hackers |
On Thu, Mar 31, 2011 at 11:11:49AM -0400, Robert Haas wrote: > On Thu, Mar 31, 2011 at 6:06 AM, Noah Misch <noah@leadboat.com> wrote: > >> I think this is a manifestation the same problem mentioned here: > >> > >> http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=31b6fc06d83c6de3644c8f2921eb7de0eb92fac3 > >> > >> I believe this requires some refactoring to fix. ?It would be good to do that. > > > > The best way I can see is to make ATExecAddColumn more like ATExecDropColumn, > > ATAddCheckConstraint, and ATExecDropConstraint. ?Namely, recurse at Exec-time > > rather than Prep-time, and cease recursing when we satisfy the ADD COLUMN with a > > merge. ?Did you have something else in mind? > > I had exactly what you just said in mind. Patch attached, then. > > Incidentally, when we satisfy an ADD COLUMN with a merge, we do not check or > > update attnotnull: <details ... what should we do?> > Not sure. I think that anything we do here is bound to have some > corner cases that are not quite right for so long as NOT NULL > constraints aren't represented in pg_constraint, and it's way too late > to dredge up that issue again for 9.1. I'm somewhat inclined to just > defer fixing it until we get that work committed. OK.
Вложения
В списке pgsql-hackers по дате отправления: