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
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.
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 ou
On Tue, Sep 17, 2013 at 12:59 PM, Robert Haas 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 complexity - the more you look
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
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
On Tue, Sep 17, 2013 at 4:54 PM, Alvaro Herrera
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 don't care much about t
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 elsew
On Tue, Sep 17, 2013 at 2:30 PM, Alvaro Herrera
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 modelling the series of
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 cor
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 app
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 head
12 matches
Mail list logo
