Re: pg_upgrade --check fails to warn about abstime

2023-09-26 Thread Suraj Kharage
On Fri, Sep 22, 2023 at 4:44 PM Alvaro Herrera wrote: > On 2023-Sep-21, Tom Lane wrote: > > > Bruce Momjian writes: > > > > Wow, I never added code to pg_upgrade to check for that, and no one > > > complained either. > > > > Yeah, so most people had indeed listened to warnings and moved away > >

Re: pg_upgrade --check fails to warn about abstime

2023-09-22 Thread Alvaro Herrera
On 2023-Sep-21, Tom Lane wrote: > Bruce Momjian writes: > > Wow, I never added code to pg_upgrade to check for that, and no one > > complained either. > > Yeah, so most people had indeed listened to warnings and moved away > from those datatypes. I'm inclined to think that adding code for this

Re: pg_upgrade --check fails to warn about abstime

2023-09-21 Thread Tom Lane
Bruce Momjian writes: > On Wed, Sep 20, 2023 at 06:54:24PM +0200, Álvaro Herrera wrote: >> I got a complaint that pg_upgrade --check fails to raise red flags when >> the source database contains type abstime when upgrading from pg11. The >> type (along with reltime and tinterval) was removed by p

Re: pg_upgrade --check fails to warn about abstime

2023-09-21 Thread Bruce Momjian
On Wed, Sep 20, 2023 at 06:54:24PM +0200, Álvaro Herrera wrote: > I got a complaint that pg_upgrade --check fails to raise red flags when > the source database contains type abstime when upgrading from pg11. The > type (along with reltime and tinterval) was removed by pg12. Wow, I never added cod

Re: pg_upgrade --check fails to warn about abstime

2023-09-20 Thread Suraj Kharage
Thanks, Alvaro, for working on this. The patch looks good to me. + * similar to the above, but for types that were removed in 12. Comment can start with a capital letter. Also, We need to backport the same, right? On Wed, Sep 20, 2023 at 10:24 PM Alvaro Herrera wrote: > I got a complaint that

Re: pg_upgrade --check fails to warn about abstime

2023-09-20 Thread Tristan Partin
On Wed Sep 20, 2023 at 12:58 PM CDT, Alvaro Herrera wrote: On 2023-Sep-20, Tristan Partin wrote: > > +/* > > + * check_for_removed_data_type_usage > > + * > > + *similar to the above, but for types that were removed in 12. > > + */ > > +static void > > +check_for_removed_data_type_usage(

Re: pg_upgrade --check fails to warn about abstime

2023-09-20 Thread Alvaro Herrera
On 2023-Sep-20, Tristan Partin wrote: > > +/* > > + * check_for_removed_data_type_usage > > + * > > + *similar to the above, but for types that were removed in 12. > > + */ > > +static void > > +check_for_removed_data_type_usage(ClusterInfo *cluster, const char > > *datatype) > > Seems l

Re: pg_upgrade --check fails to warn about abstime

2023-09-20 Thread Tristan Partin
+/* + * check_for_removed_data_type_usage + * + *similar to the above, but for types that were removed in 12. + */ +static void +check_for_removed_data_type_usage(ClusterInfo *cluster, const char *datatype) Seems like you could make this more generic instead of hardcoding version 12, an

pg_upgrade --check fails to warn about abstime

2023-09-20 Thread Alvaro Herrera
I got a complaint that pg_upgrade --check fails to raise red flags when the source database contains type abstime when upgrading from pg11. The type (along with reltime and tinterval) was removed by pg12. In passing, while testing this, I noticed that the translation infrastructure in pg_upgrade