Peter Eisentraut wrote: > This could probably be sorted out somehow, but I don't want > to be too lax now and cause problems for later features. There is a > similar case, namely changing the return type of a function, which we > also prohibit.
Consider the case of a table with a SERIAL column which later has to become a BIGINT due to growth. Currently a user would just alter the column's type and does need to do anything with the sequence. With the patch, it becomes a problem because - ALTER SEQUENCE seqname MAXVALUE new_value will fail because new_value is beyond the range of INT4. - ALTER SEQUENCE seqname TYPE BIGINT does not exist (yet?) - DROP SEQUENCE seqname (with the idea of recreating the sequence immediately after) will be rejected because the table depends on the sequence. What should a user do to upgrade the SERIAL column? BTW, I notice that a direct UPDATE of pg_sequence happens to work (now that we have pg_sequence thanks to your other recent contributions on sequences), but I guess it falls under the rule mentioned in https://www.postgresql.org/docs/devel/static/catalogs.html "You can drop and recreate the tables, add columns, insert and update values, and severely mess up your system that way. Normally, one should not change the system catalogs by hand, there are normally SQL commands to do that" Previously, UPDATE seqname SET property=value was rejected with a specific error "cannot change sequence". Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
