Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changing column data type does not create an ALTER TABLE statement #215

Open
wireman27 opened this issue Dec 10, 2019 · 3 comments
Open

Comments

@wireman27
Copy link

Given an initial YAML specification as so:

table prop_tax:
    columns:
    - hsh:
        type: character varying(16)
    - locality_text:
        type: character varying
    - locality_value:
        type: smallint

and then changing it to:

table prop_tax:
    columns:
    - hsh:
        type: character varying(32)
    - locality_text:
        type: character varying
    - locality_value:
        type: smallint

doesn't issue an SQL statement. What am I missing?

@jmafc jmafc added the yamltodb label Dec 10, 2019
@jmafc
Copy link
Member

jmafc commented Dec 10, 2019

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.

@wireman27
Copy link
Author

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!

@jmafc
Copy link
Member

jmafc commented Dec 10, 2019

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.

@jmafc jmafc reopened this Dec 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants