Milan Zazrivec wrote:
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.
Well, unlike the other constraints such as PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK, etc
..., the NULL-ability is typically managed via keyword and is stored with the column
definition itself. As such, it can (and usually is) managed via NOT NULL or NULL
keyword(s) using a simple ALTER TABLE statement. Most of the other constraints can be
added by keyword but unlike NOT NULL can only be removed by dropping the constraint by
name. At least as far as I know. So, to support upgrade scripts, the other constraints
must remain named. So, unlike the other constraints, creating the NOT NULL named
constraint has no value and adds cruft to the table definition.
- 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?
If you are familiar with the upgrade validation scripts and can make this change then I
would greatly appreciate your doing so :-)
-MZ
_______________________________________________
Spacewalk-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-devel
_______________________________________________
Spacewalk-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-devel
