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

Reply via email to