Piotr Stefaniak
writes:
> On 16/01/2020 03.59, Thomas Munro wrote:
>> One way to fix that in the cases Alvaro is referring to is to tell
>> override the setting so that && (and likewise ||) are never considered
>> to be unary, though I haven't tested this much and there are surely
>> other ways
On 16/01/2020 03.59, Thomas Munro wrote:
On Wed, Jan 15, 2020 at 11:30 AM Tom Lane wrote:
Alvaro Herrera writes:
I just ran pgindent over some patch, and noticed that this hunk ended up
in my working tree:
- if (IsA(leftop, Var) && IsA(rightop, Const))
+ if (IsA(leftop, Var) &&IsA(
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Thomas Munro writes:
> > It seems I cannot. Please go ahead.
>
> [ yawn... ] It's about bedtime here, but I'll take care of it in the
> morning.
>
> Off the critical path, we oughta figure out why the repo wouldn't
> let you commit. What I
Thomas Munro writes:
> On Sat, May 16, 2020 at 10:15 AM Tom Lane wrote:
>> +1. I think the repo will let you in, but if not, I can do it.
> It seems I cannot. Please go ahead.
Pushed, and I bumped pg_bsd_indent's version to 2.1.1, and synced
our core repo with that.
r
Thomas Munro writes:
> On Sat, May 16, 2020 at 10:15 AM Tom Lane wrote:
>> +1. I think the repo will let you in, but if not, I can do it.
> It seems I cannot. Please go ahead.
[ yawn... ] It's about bedtime here, but I'll take care of it in the
morning.
Off the critical path, we oughta figu
On Sat, May 16, 2020 at 10:15 AM Tom Lane wrote:
> Thomas Munro writes:
> > Here's the patch I propose to commit to pg_bsd_indent, if the repo
> > lets me, and here's the result of running it on the PG tree today.
>
> +1. I think the repo will let you in, but if not, I can do it.
It seems I can
Alvaro Herrera writes:
> On 2020-May-16, Thomas Munro wrote:
>> Here's the patch I propose to commit to pg_bsd_indent, if the repo
>> lets me, and here's the result of running it on the PG tree today.
> Looks good. Of all these changes in PG, only two are of the STACK_OK()
> nature, and there ar
On 2020-May-16, Thomas Munro wrote:
> Here's the patch I propose to commit to pg_bsd_indent, if the repo
> lets me, and here's the result of running it on the PG tree today.
Looks good. Of all these changes in PG, only two are of the STACK_OK()
nature, and there are 38 places that get better.
>
Thomas Munro writes:
> Here's the patch I propose to commit to pg_bsd_indent, if the repo
> lets me, and here's the result of running it on the PG tree today.
+1. I think the repo will let you in, but if not, I can do it.
regards, tom lane
On Tue, Feb 18, 2020 at 12:42 PM Tom Lane wrote:
> Thomas Munro writes:
> > Another problem is that there is one thing in our tree that looks like
> > a non-cast under the new rule, but it actually expands to a type name,
> > so now we get that wrong! (I mean, unpatched indent doesn't really
> >
Thomas Munro writes:
> Another problem is that there is one thing in our tree that looks like
> a non-cast under the new rule, but it actually expands to a type name,
> so now we get that wrong! (I mean, unpatched indent doesn't really
> understand it either, it thinks it's a cast, but at least i
On Tue, Feb 18, 2020 at 4:35 AM Alvaro Herrera wrote:
> Hmm ... this suggests to me that if you remove these alleged special
> cases for offsetof and sizeof, the new code handles them correctly
> anyway. Do you think it's worth giving that a try? Not because
> removing the special cases would ha
On 2020-Feb-17, Thomas Munro wrote:
> Thinking about this again: It's obviously not true that everything
> that looks like a function call is not a cast. You could have
> "my_cast(Type)" that expands to "(Type)" or some slightly more useful
> variant of that, and then "my_cast(Type) -1" would, wi
On Fri, Jan 17, 2020 at 3:58 PM Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2020-Jan-16, Tom Lane wrote:
> >> ... But I was hoping to
> >> hear Piotr's opinion before moving forward.
Me too.
Thinking about this again: It's obviously not true that everything
that looks like a function call i
Alvaro Herrera writes:
> On 2020-Jan-16, Tom Lane wrote:
>> ... But I was hoping to
>> hear Piotr's opinion before moving forward.
> FWIW I think this code predates Piotr's involvement, I think; at least,
> it was already there in the FreeBSD code he imported:
> https://github.com/pstef/freebsd_i
On 2020-Jan-16, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2020-Jan-17, Michael Paquier wrote:
> >> Nice find! Could you commit that? I can see many places improved as
> >> well, among explain.c, tablecmds.c, typecmds.c, and much more.
>
> > I think Tom is the only one who can commit tha
Alvaro Herrera writes:
> On 2020-Jan-17, Michael Paquier wrote:
>> Nice find! Could you commit that? I can see many places improved as
>> well, among explain.c, tablecmds.c, typecmds.c, and much more.
> I think Tom is the only one who can commit that,
> https://git.postgresql.org/gitweb/?p=pg_
On 2020-Jan-17, Michael Paquier wrote:
> On Thu, Jan 16, 2020 at 06:13:36PM -0300, Alvaro Herrera wrote:
> > This is indeed a very good fix! Several badly formatted sites in our
> > code are improved with this change.
>
> Nice find! Could you commit that? I can see many places improved as
> we
On Thu, Jan 16, 2020 at 06:13:36PM -0300, Alvaro Herrera wrote:
> This is indeed a very good fix! Several badly formatted sites in our
> code are improved with this change.
Nice find! Could you commit that? I can see many places improved as
well, among explain.c, tablecmds.c, typecmds.c, and mu
On 2020-Jan-17, Thomas Munro wrote:
> On Thu, Jan 16, 2020 at 3:59 PM Thomas Munro wrote:
> > On Wed, Jan 15, 2020 at 11:30 AM Tom Lane wrote:
> > > Yeah, it's been doing that for decades. I think the triggering
> > > factor is the typedef name (Var, here) preceding the &&.
>
> Here's a better
On Thu, Jan 16, 2020 at 3:59 PM Thomas Munro wrote:
> On Wed, Jan 15, 2020 at 11:30 AM Tom Lane wrote:
> > Yeah, it's been doing that for decades. I think the triggering
> > factor is the typedef name (Var, here) preceding the &&.
Here's a better fix:
diff --git a/indent.c b/indent.c
index 9fa
On Wed, Jan 15, 2020 at 11:30 AM Tom Lane wrote:
> Alvaro Herrera writes:
> > I just ran pgindent over some patch, and noticed that this hunk ended up
> > in my working tree:
>
> > - if (IsA(leftop, Var) && IsA(rightop, Const))
> > + if (IsA(leftop, Var) &&IsA(rightop, Const))
>
> Yeah, i
On Tue, Jan 14, 2020 at 05:30:21PM -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > I just ran pgindent over some patch, and noticed that this hunk ended up
> > in my working tree:
>
> > - if (IsA(leftop, Var) && IsA(rightop, Const))
> > + if (IsA(leftop, Var) &&IsA(rightop, Const))
>
>
Alvaro Herrera writes:
> I just ran pgindent over some patch, and noticed that this hunk ended up
> in my working tree:
> - if (IsA(leftop, Var) && IsA(rightop, Const))
> + if (IsA(leftop, Var) &&IsA(rightop, Const))
Yeah, it's been doing that for decades. I think the triggering
factor
I just ran pgindent over some patch, and noticed that this hunk ended up
in my working tree:
diff --git a/src/backend/statistics/extended_stats.c
b/src/backend/statistics/extended_stats.c
index 861a9148ed..fff54062b0 100644
--- a/src/backend/statistics/extended_stats.c
+++ b/src/backend/statistic
25 matches
Mail list logo
