On Tue, 14 Jan 2025 13:58:18 +
Dean Rasheed wrote:
> On Tue, 14 Jan 2025 at 08:44, Yugo NAGATA wrote:
> >
> > I've attached a updated patch v4 that includes fixes on translate_columns[]
> > and ranslate_columns_pre_96[].
> >
>
> This looked good to me, so I've pushed both patches.
>
> I ch
On Tue, 14 Jan 2025 at 08:44, Yugo NAGATA wrote:
>
> I've attached a updated patch v4 that includes fixes on translate_columns[]
> and ranslate_columns_pre_96[].
>
This looked good to me, so I've pushed both patches.
I changed the column name to "Leakproof?" with a question mark,
because all oth
On Fri, 10 Jan 2025 11:31:39 +
Dean Rasheed wrote:
> On Wed, 4 Dec 2024 at 11:21, Yugo NAGATA wrote:
> >
> > > Looking through the complete list of psql meta-commands, "leakproof"
> > > could plausibly be added to the output of each of the following:
> > >
> > > \dAo+
> > > \dC+
> > > \df+
>
On Wed, 4 Dec 2024 at 11:21, Yugo NAGATA wrote:
>
> > Looking through the complete list of psql meta-commands, "leakproof"
> > could plausibly be added to the output of each of the following:
> >
> > \dAo+
> > \dC+
> > \df+
> > \do+
>
> I've attached a updated patch (v3-0001) that include changes
_proc.h
@@ -61,7 +61,7 @@ CATALOG(pg_proc,1255,ProcedureRelationId) BKI_BOOTSTRAP BKI_ROWTYPE_OID(81,Proce
/* security definer */
bool prosecdef BKI_DEFAULT(f);
- /* is it a leak-proof function? */
+ /* is it a leakproof function? */
bool proleakproof BKI_DEFAULT(f);
/* strict with respect to NULLs? */
--
2.34.1
>F
On Fri, Nov 15, 2024 at 05:26:08PM +, Dean Rasheed wrote:
> Yes, I think we should do that (in a separate patch).
$ git grep "leakproof" | wc -l
544
$ git grep "leak-proof" | wc -l
8
So there's a clear winner here.
--
Michael
signature.asc
Description: PGP signature
On Fri, 15 Nov 2024 at 09:55, Yugo Nagata wrote:
>
> I'll fixed the patch to add leakproof info to \do+ results, but is it worth
> leaving this info in \dAo+ results, too?
>
I suppose that might still be useful in some contexts.
Looking through the complete list of psql meta-commands, "leakproof
On Mon, 4 Nov 2024 11:00:41 +
Dean Rasheed wrote:
> > On 2024-07-01 15:08 +0200, Yugo NAGATA wrote:
> > I would like to propose to add a new field to psql's \dAo+ meta-command
> > to show whether the underlying function of an operator is leak-proof.
> >
>
> I agree that this is useful inform
> On 2024-07-01 15:08 +0200, Yugo NAGATA wrote:
> I would like to propose to add a new field to psql's \dAo+ meta-command
> to show whether the underlying function of an operator is leak-proof.
>
I agree that this is useful information to have, but why add it to
\dAo+ instead of \do+? Taking the e
On 2024-07-30 08:30 +0200, Yugo NAGATA wrote:
> On Tue, 30 Jul 2024 01:36:55 +0200
> Erik Wienhold wrote:
>
> > On 2024-07-01 15:08 +0200, Yugo NAGATA wrote:
> > > I would like to propose to add a new field to psql's \dAo+ meta-command
> > > to show whether the underlying function of an operator
onsistent with the other CASE expressions in this query.
Fixed both.
Regards,
Yugo Nagata
>
> [1] https://www.postgresql.org/docs/devel/planner-stats-security.html
>
> --
> Erik
--
Yugo NAGATA
>From ca41705da15ca588d55f3c2cc2106284911e53a1 Mon Sep 17 00:00:00 2001
From:
On 2024-07-01 15:08 +0200, Yugo NAGATA wrote:
> I would like to propose to add a new field to psql's \dAo+ meta-command
> to show whether the underlying function of an operator is leak-proof.
+1 for making that info easily accessible.
> This idea is inspired from [1] that claims some indexes uses
AGATA
>From 3417c4cce46ec068464b7069428e7f4a9a2cd07d Mon Sep 17 00:00:00 2001
From: Yugo Nagata
Date: Mon, 1 Jul 2024 16:16:39 +0900
Subject: [PATCH] psql: Add leakproof field to \dAo+ meta-command results
This adds a field that shows whether the underlying function of an
operator associated with
13 matches
Mail list logo
