On 03/03/2018 01:56 AM, Tom Lane wrote: > Tomas Vondra <tomas.von...@2ndquadrant.com> writes: >> OK, time to revive this old thread ... >>>> [ scalarineqsel may fall over when used by extension operators ] > >> Attached is a minimal fix adding a flag to convert_numeric_to_scalar, >> tracking when it fails because of unsupported data type. If any of the 3 >> calls (value + lo/hi boundaries) sets it to 'true' we simply fall back >> to the default estimate (0.5) within the bucket. > > I think this is a little *too* minimal, because it only covers > convert_numeric_to_scalar and not the other sub-cases in which > convert_to_scalar will throw an error instead of returning "false". > I realize that that would be enough for your use-case, but I think > we need to think more globally. So please fix the other ones too. >
Will do. > I notice BTW that whoever shoehorned in the bytea case failed to > pay attention to the possibility that not all three inputs are > of the same type; so that code is flat out broken, and capable > of crashing if fed dissimilar types. We ought to deal with that > while we're at it, since (IMO) the goal is to make convert_to_scalar > fail-soft for any combination of supplied data types. > OK, I'll look into that too. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services