Re: BUG #17066: Cache lookup failed when null (iso-8859-1) is passed as anycompatiblemultirange - Mailing list pgsql-bugs

From Alexander Korotkov
Subject Re: BUG #17066: Cache lookup failed when null (iso-8859-1) is passed as anycompatiblemultirange
Date
Msg-id CAPpHfds+2wNNWjpgmDbRxiHf=8jj1yUGM6NWt71eTH-uAkFr-A@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17066: Cache lookup failed when null (iso-8859-1) is passed as anycompatiblemultirange  (Alexander Korotkov <aekorotkov@gmail.com>)
List pgsql-bugs
On Wed, Jun 30, 2021 at 1:06 AM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> On Thu, Jun 24, 2021 at 2:35 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > Alexander Korotkov <aekorotkov@gmail.com> writes:
> > > I really appreciate a hint here.
> >
> > I think I'm to blame for most of that code originally, so I'll take
> > a look soon.  Been up to my neck in other stuff recently.
>
> Do I understand correctly that enforce_generic_type_consistency() is
> called only after check_generic_type_consistency() returned true?
>
> If so, that means some of the checks are redundant.  Therefore, we can
> replace ereport()'s with Assert()'s.

I got no feedback on this yet.  And 14beta3 is approaching...

I'm going to write a patch fixing enforce_generic_type_consistency()
while saving its general logic (as far as I can understand it).

------
Regards,
Alexander Korotkov



pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #17111: Database created, cannot be created, but reported as inexist
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: BUG #17103: WAL segments are not removed after exceeding max_slot_wal_keep_size