Re: Is MinMaxExpr really leakproof?

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Is MinMaxExpr really leakproof?
Date: 2019-01-02 13:16:42
Message-ID: 20190102131642.GY2528@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings,

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Noah Misch <noah(at)leadboat(dot)com> 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 clear that we'd gain much from insisting
> on leakproofness in general, and it seems like it might be rather a
> large burden to put on add-on data types.

While I'd actually like it if we required leakproofness for what we
ship, I agree that we shouldn't blindly assume that add-on data types
are always leakproof and that then requires that we explicitly verify
it. Perhaps an argument can be made that there are some cases where
what we ship can't or shouldn't be leakproof for usability but, ideally,
those would be relatively rare exceptions that don't impact common
use-cases.

Thanks!

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei KaiGai 2019-01-02 13:34:04 Re: add_partial_path() may remove dominated path but still in use
Previous Message Stephen Frost 2019-01-02 12:54:14 Re: [HACKERS] REINDEX CONCURRENTLY 2.0