You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered: