Open wireman27 opened 4 years ago
The short answer is that changing a datatype declaration is generally not trivial. Take the converse of you example. If you issue ALTER TABLE prop_tax ALTER hsh TYPE varchar(16)
when hsh
is defined a varchar(32), one of two things may happen: if the table is empty or all hsh
values are 16 characters or shorter, PG will accept the statement, but if just one value is 17 bytes or longer, the ALTER will be rejected. There are of course, many more complicated conversions, like text
to date
, even if all text values were nicely formatted as date
values, or non-sensical conversions.
Arguably, yamltodb
could behave differently. It could flag any datatype changes as errors, it could try to deal correctly with some subset of allowed changes like varchar(n) to varchar(p) where p > n, or it could issue the ALTER TABLE and let the user deal with any undesirable consequences.
Ahh, I didn't quite think about the non-triviality because I tried making these changes when there was no data yet in the column. Beautifully explained, thanks very much!
Thanks for the appreciative comment. I do believe that at the very least we should update our "Known Issues" to highlight the fact that an ALTER TABLE
is not issued in these circumstances. So I'm going to re-open it and mark it as 'documentation', although ideally we ought to do more than that.
Given an initial YAML specification as so:
and then changing it to:
doesn't issue an SQL statement. What am I missing?