On 2019-09-21 22:30, Tom Lane wrote:
> I wrote:
>> Peter Eisentraut writes:
Here is a draft patch.
>
>> Where are we on pushing that? I'm starting to get antsy about the
>> amount of time remaining before rc1. It's a low-risk fix, but still,
>> it'd be best to have a complete buildfarm
Peter Eisentraut writes:
>> Here is a draft patch.
Where are we on pushing that? I'm starting to get antsy about the
amount of time remaining before rc1. It's a low-risk fix, but still,
it'd be best to have a complete buildfarm cycle on it before Monday's
wrap.
Peter Eisentraut writes:
> Here is a draft patch.
> It will require a catversion change because those operator classes don't
> have assigned OIDs so far.
That's slightly annoying given where we are with v12. We could
avoid it by looking up the opclass's opfamily and seeing if it's
On 2019-09-17 17:17, Tom Lane wrote:
> My recommendation is to get rid of the run-time checks and instead
> put a hack like this into DefineIndex or some minion thereof:
>
> if ((opclass == TEXT_PATTERN_BTREE_CLASS_OID ||
>opclass == VARCHAR_PATTERN_BTREE_CLASS_OID ||
>
Peter Eisentraut writes:
> On 2019-09-17 01:13, Tom Lane wrote:
>> Whilst poking at the leakproofness-of-texteq issue, I realized
>> that there's an independent problem caused by the nondeterminism
>> patch. To wit, that the text_pattern_ops btree opclass uses
>> texteq as its equality operator,
On 2019-09-17 01:13, Tom Lane wrote:
> Whilst poking at the leakproofness-of-texteq issue, I realized
> that there's an independent problem caused by the nondeterminism
> patch. To wit, that the text_pattern_ops btree opclass uses
> texteq as its equality operator, even though that operator is
>
