On Fri, Aug 2, 2024 at 6:58 AM Joe Conway <m...@joeconway.com> wrote:
> On 8/2/24 09:48, Jacob Champion wrote: > > On Thu, Aug 1, 2024 at 6:03 PM Robert Haas <robertmh...@gmail.com> > wrote: > >> > >> On Thu, Aug 1, 2024 at 4:45 PM Jacob Champion > >> <jacob.champ...@enterprisedb.com> wrote: > >> > Would it provide enough value for effort to explicitly mark leaky > >> > procedures as such? Maybe that could shrink the grey area enough to be > >> > protective? > >> > >> You mean like proleakproof = true/false/maybe? > > > > Yeah, exactly. > > <dons flameproof suit> > Hmmm, and then have "leakproof_mode" = strict/lax/off where 'strict' is > current behavior, 'lax' allows the 'maybe's to get pushed down, and > 'off' ignores the leakproof attribute entirely and pushes down anything > that merits being pushed? > </dons flameproof suit> > > Another approach would be to do something like: select "upper"!(column) to demark within the query usage itself that this function with a maybe leakproof attribute gets interpreted as yes. or even something like: select "upper"[leakproof](column) This is both more readable and provides a way, not that we seem to need it, to place more than one label (or just alternative labels using the same syntax construct, like with explain (...)) inside the "array". Discoverability of when to add such a marker would be left up to the query author, with the safe default mode being a not leakproof interpretation. David J.
