On Thursday 21 May 2009 22:23:17 Jeff Ortel wrote: > All, > > The outcome of the meeting yesterday regarding the pgsql branch review is > as follows: > > After lengthy discussion it was decided (almost unanimously by attendance) > that the work on the pgsql branch would be merged to master without > refactoring the commits. There was general agreement that the concerns and > objections raised about doing this had a lot of merit. However, they did > not justify the effort required to re-implement work that has already been > completed. > > Pending resolution of the following content related comments and assuming > no new issues are raised, the branch will be merged to master. Merge vs > cherry pick, not sure which is best. Thoughts anyone? > > Content related concerns to be addressed before merging pgsql to master: > > * Trailing white space needs to be removed. > > I will trim the trailing white spaces. > > * Packaging of upgrade scripts needs to be resolved. > > I committed a change to pgsql branch that will *undo* the proposed > changes to the packaging and installation of the upgrade scripts. They > will be installed in same place and have the same form as before. This > means that initially, upgrades will only be for oracle installs. After the > dust settles on the merge to master we will revisit the upgrades. > > * Replacing the named NOT NULL constraints in the common tables (.sql) > files with simple NOT NULL keywords.
I still don't understand why this thing was done for some not null constraints and not for foreign keys for example. > - Concern about the upgrade scripts. > > Using "ALTER TABLE <table> MODIFY <column> NULL;" > instead of: > "ALTER TABLE <table> DROP CONSTRAINT <constraint name>;" to make a > column nullable in all future upgrade scripts will handle this. > > - The change causes problems in the upgrade verification scripts > because the named NOT NULL constraints will be squawked as missing. > > Unfortunately, when looking at user_constraints, the > constraint_type=R is for both CHECK constraints and NOT NULL constraints. > But, the search_condition can easily be used to ignore NOT NULL > constraints. Validation that the column is NOT NULL, can be done by > matching the nullable column in user_tab_columns when validating a table's > columns. I believe the effort to tweak the upgrade validation scripts will > be much less then reworking the common tables (.sql) files to restore the > named NOT NULL constraints. Should I understand this so that we will relax from the requirement on schema equivalence and ignore the differences in constraint names? -MZ _______________________________________________ Spacewalk-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-devel
