This is an automated backport of #6940: Remove regprocedure oid type from catalog.
The original issue is #6935.
This PR will not be merged automatically, because it modifies 'sql/updates/reverse-dev.sql' which is conflict-prone. Please review these changes manually. If this fix should not be backported, or will be backported manually, just close this PR. You can use the backport branch to add your changes, it won't be modified automatically anymore.
In https://github.com/timescale/timescaledb/pull/6624 we refactored the time bucket catalog table to make it more
generic and save information for all Continuous Aggregates. Previously it stored only variable bucket size information.
The problem is we used the regprocedure type to store the OID of the given time bucket function but unfortunately it is not supported by pg_upgrade.
Fixed it by changing the column to TEXT and resolve to/from OID using builtin regprocedurein and format_procedure_qualified functions.
This is an automated backport of #6940: Remove regprocedure oid type from catalog. The original issue is #6935. This PR will not be merged automatically, because it modifies 'sql/updates/reverse-dev.sql' which is conflict-prone. Please review these changes manually. If this fix should not be backported, or will be backported manually, just close this PR. You can use the backport branch to add your changes, it won't be modified automatically anymore.
For more details, please see the documentation
Original description
Remove regprocedure oid type from catalog
In https://github.com/timescale/timescaledb/pull/6624 we refactored the time bucket catalog table to make it more generic and save information for all Continuous Aggregates. Previously it stored only variable bucket size information.
The problem is we used the
regprocedure
type to store the OID of the given time bucket function but unfortunately it is not supported bypg_upgrade
.Fixed it by changing the column to TEXT and resolve to/from OID using builtin
regprocedurein
andformat_procedure_qualified
functions.Fixes
#6935