Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> So I'd like to get to a point where we're comfortable marking these
> >> functions leakproof despite the possibility of corner-case failures.
> >> We could just decide that
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> So I'd like to get to a point where we're comfortable marking these
>> functions leakproof despite the possibility of corner-case failures.
>> We could just decide that the existing failure cases in varstr_cmp are
>> not usefully
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Noah Misch writes:
> >>> Either of those solutions sounds fine. Like last time, I'll vote for
> >>> explicitly
> >>> verifying leakproofness.
>
> >> Yeah, I'm leaning in
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Noah Misch writes:
>>> Either of those solutions sounds fine. Like last time, I'll vote for
>>> explicitly
>>> verifying leakproofness.
>> Yeah, I'm leaning in that direction as well. Other than comparisons
>> involving
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Noah Misch writes:
> > Either of those solutions sounds fine. Like last time, I'll vote for
> > explicitly
> > verifying leakproofness.
>
> Yeah, I'm leaning in that direction as well. Other than comparisons
> involving strings, it's not
> "Tom" == Tom Lane writes:
>> bttextcmp() and other varstr_cmp() callers fall afoul of the same
>> restriction with their "could not convert string to UTF-16" errors
>> (https://postgr.es/m/CADyhKSXPwrUv%2B9LtqPAQ_gyZTv4hYbr2KwqBxcs6a3Vee1jBLQ%40mail.gmail.com).
>> Leaking the binary
Isaac Morland writes:
> On Mon, 31 Dec 2018 at 12:26, Noah Misch wrote:
>> bttextcmp() and other varstr_cmp() callers fall afoul of the same
>> restriction with their "could not convert string to UTF-16" errors
> I'm confused. What characters cannot be represented in UTF-16?
What's actually
Noah Misch writes:
> This thread duplicates
> https://postgr.es/m/flat/16539.1431472961%40sss.pgh.pa.us
Ah, so it does. Not sure why that fell off the radar without getting
fixed; possibly because it was right before PGCon.
> pg_lsn_cmp() and btoidvectorcmp() surely could advertise
This thread duplicates https://postgr.es/m/flat/16539.1431472961%40sss.pgh.pa.us
On Sun, Dec 30, 2018 at 01:24:02PM -0500, Tom Lane wrote:
> So this coding amounts to an undocumented
> assumption that every non-cross-type btree comparison function is
> leakproof.
> select p.oid::regprocedure
