Thanks all for reply! Robert,
> Doing it based on an index scan doesn't necessarily seem like a good idea. We > have > no guarantee at all that the index scan will be faster than scanning > the table would have been I agree this. Thinking a little about idea of index scan i can not give reasonable usecase which required index. My target problem of adding NOT NULL to big relation without long downtime can be done with ADD CONSTRAINT NOT VALID, VALIDATE it in second transaction, then SET NOT NULL by my patch and drop unneeded constraint. Stephen, > Just, generally speaking, this is definitely something that I think we > want and neither of the above concerns seem like they're technical > reasons why we can't use something like this approach, just needs to > perhaps be reworked to handle multiple columns in a single query. I understood the idea, thank you. Tom, > I did not look at the patch yet, but TBH if it uses SPI for sub-operations > of ALTER TABLE I think that is sufficient reason to reject it out of hand. I understood, thank you. So, i will soon delete SPI usage and index scan and post new simplified patch with verify data only by constraints.
