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
