On Wed, Oct 2, 2013 at 08:59:42AM -0400, Noah Misch wrote:
On Tue, Oct 01, 2013 at 10:12:05PM -0400, Bruce Momjian wrote:
If we had not made massive cleanup changes years ago, our code would not
be as good as it is today. By avoiding cleanup to reduce the burden on
people who use our
On Tue, Oct 01, 2013 at 10:12:05PM -0400, Bruce Momjian wrote:
If we had not made massive cleanup changes years ago, our code would not
be as good as it is today. By avoiding cleanup to reduce the burden on
people who use our code, we are positioning our code on a slow decline
in clarity.
Bruce Momjian escribió:
On Wed, Oct 2, 2013 at 08:59:42AM -0400, Noah Misch wrote:
On Tue, Oct 01, 2013 at 10:12:05PM -0400, Bruce Momjian wrote:
If we had not made massive cleanup changes years ago, our code would not
be as good as it is today. By avoiding cleanup to reduce the burden
On Tue, Sep 17, 2013 at 05:54:04PM -0300, Alvaro Herrera wrote:
I don't want to be too dogmatic in opposing this; I accept that we
should, from time to time, refactor things. If we don't, superflouous
dependencies will probably proliferate over time. But personally, I'd
rather do these
On Tue, Sep 17, 2013 at 12:59 PM, Robert Haas robertmh...@gmail.com wrote:
Personally, I'm not particularly in favor of these kinds of changes.
+1. Experience has shown this kind of effort to be a tarpit. It turns
out that refactoring away compiler dependencies has this kind of
fractal
On Tue, Sep 17, 2013 at 4:54 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Now, htup_details.h was a bit different than the case at hand because
there's evidently lots of code that want to deal with the guts of
tuples, but for scans you mainly want to start one, iterate and finish,
but
On Tue, Sep 17, 2013 at 05:54:04PM -0300, Alvaro Herrera wrote:
Robert Haas escribi?:
Personally, I'm not particularly in favor of these kinds of changes.
The changes we made last time broke a lot of extensions - including
some proprietary EDB ones that I had to go fix. I think a lot of
On Mon, Sep 16, 2013 at 11:02:28PM -0300, Alvaro Herrera wrote:
relscan.h is a bit of an unfortunate header because it requires a lot of
other headers to compile, and is also required by execnodes.h. This
Not in my copy of the source tree. execnodes.h uses the corresponding
typedefs that
Noah Misch wrote:
On Mon, Sep 16, 2013 at 11:02:28PM -0300, Alvaro Herrera wrote:
relscan.h is a bit of an unfortunate header because it requires a lot of
other headers to compile, and is also required by execnodes.h. This
Not in my copy of the source tree. execnodes.h uses the
On Tue, Sep 17, 2013 at 2:30 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
-1 on header restructuring in the absence of noteworthy compile-time
benchmark
improvements. Besides the obvious benchmark of full-build time, one could
exercise the benefit of fewer header dependencies by
Robert Haas escribió:
Personally, I'm not particularly in favor of these kinds of changes.
The changes we made last time broke a lot of extensions - including
some proprietary EDB ones that I had to go fix. I think a lot of
people spent a lot of time fixing broken builds, at EDB and
relscan.h is a bit of an unfortunate header because it requires a lot of
other headers to compile, and is also required by execnodes.h. This
quick patch removes the struct definitions from that file, moving them
into a new relscan_details.h file; the reworked relscan.h does not need
any other
12 matches
Mail list logo
