On Fri, Feb 28, 2025 at 9:52 AM Robert Haas wrote:
> On Thu, Feb 27, 2025 at 4:48 PM Tom Lane wrote:
> > Oversight I assume?
>
> Yeah, that was dumb. Thanks for catching it. Here's v3.
Committed so I can see what the buildfarm thinks before it gets too
late in the day.
--
Robert Haas
EDB: http
On Thu, Feb 27, 2025 at 4:48 PM Tom Lane wrote:
> Oversight I assume?
Yeah, that was dumb. Thanks for catching it. Here's v3.
--
Robert Haas
EDB: http://www.enterprisedb.com
v3-0001-Avoid-including-explain.h-in-explain_format.h-and.patch
Description: Binary data
On Thu, Feb 27, 2025 at 4:12 PM Tom Lane wrote:
> +1, but how about explain_dr.h too? It doesn't seem though that
> we can avoid #include "executor/instrument.h" there, so it'd be
> a little asymmetrical. But the executor inclusion doesn't seem
> nearly as much almost-circular.
OK, here is v2.
Robert Haas writes:
> OK, here is v2. One slightly unfortunate thing about this is that we
> end up with a line that is over 80 characters:
> extern DestReceiver *CreateExplainSerializeDestReceiver(struct
> ExplainState *es);
> Aside from perhaps shortening the function name, I don't see how to
Robert Haas writes:
> On Thu, Feb 27, 2025 at 3:05 PM Tom Lane wrote:
>> Did you look at avoiding that with our standard trick of writing
>> detail-free struct declarations?
> OK, here's a patch that does that. Thoughts?
+1, but how about explain_dr.h too? It doesn't seem though that
we can av
On Thu, Feb 27, 2025 at 3:05 PM Tom Lane wrote:
> Robert Haas writes:
> > The thing that was bugging me a bit is that explain_format.h includes
> > explain.h.
>
> Yeah, I did not like that at all either -- it makes things a bit
> circular, and I fear IWYU is going to make stupid recommendations
>
Robert Haas writes:
> The thing that was bugging me a bit is that explain_format.h includes
> explain.h.
Yeah, I did not like that at all either -- it makes things a bit
circular, and I fear IWYU is going to make stupid recommendations
like not including explain.h in explain.c.
Did you look at a
On Thu, Feb 27, 2025 at 2:21 PM Álvaro Herrera wrote:
> On 2025-Feb-27, Robert Haas wrote:
> > I see that the Redis-FDW test is failing; it will now need to include
> > "commands/explain_format.h" -- unless we something, of course.
>
> I wonder if it was really a useful idea to move the declarati
On 2025-Feb-27, Robert Haas wrote:
> I see that the Redis-FDW test is failing; it will now need to include
> "commands/explain_format.h" -- unless we something, of course.
I wonder if it was really a useful idea to move the declarations of
those functions from explain.h to the new explain_format
On Thu, Feb 27, 2025 at 1:24 PM Robert Haas wrote:
> Thanks for the quick response! I have committed these patches.
I recently did something similar myself when I moved all of the nbtree
preprocessing code into its own file.
The obvious downside is that it tends to make "git blame" much less
use
On Tue, Feb 18, 2025 at 1:11 PM Peter Geoghegan wrote:
> On Tue, Feb 18, 2025 at 1:04 PM Robert Haas wrote:
> > I think in cases like this there is a tendency to want to achieve an
> > even split of the original file, but in practice I think that tends
> > not to be difficult to achieve. These tw
On Tue, Feb 18, 2025 at 1:04 PM Robert Haas wrote:
> I think in cases like this there is a tendency to want to achieve an
> even split of the original file, but in practice I think that tends
> not to be difficult to achieve. These two patches combined move about
> 1000 lines of code into separate
While contemplating some additions to explain.c, I noticed that this
file has become rather large -- 5924 lines on master. I'm generally
not a fan of very large source files, and I think it would be a good
idea to start splitting this one up before things get completely out
of control. Here are a f
13 matches
Mail list logo
