Excerpts from David Fetter's message of lun oct 17 03:00:19 -0300 2011:
> On Fri, Oct 14, 2011 at 07:36:32PM +0100, Peter Geoghegan wrote:
> > This evening, David Fetter described a problem to me that he was
> > having building the Twitter FDW. It transpired that it was down to its
> > dependence
On Fri, Oct 14, 2011 at 07:36:32PM +0100, Peter Geoghegan wrote:
> This evening, David Fetter described a problem to me that he was
> having building the Twitter FDW. It transpired that it was down to its
> dependence on an #include that was recently judged to be
> redundant.This seems like another
Excerpts from Peter Geoghegan's message of vie oct 14 15:36:32 -0300 2011:
> This evening, David Fetter described a problem to me that he was
> having building the Twitter FDW. It transpired that it was down to its
> dependence on an #include that was recently judged to be
> redundant.This seems l
This evening, David Fetter described a problem to me that he was
having building the Twitter FDW. It transpired that it was down to its
dependence on an #include that was recently judged to be
redundant.This seems like another reason to avoid using pgrminclude -
even if we can be certain that the #
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Actually, I believe that the *main* problem with pgrminclude is that
> >> it fails to account for combinations of build options other than those
> >> that Bruce uses. In the previous go-round, the reason we were still
> >> squashing
On 09/24/2011 01:10 PM, Peter Geoghegan wrote:
On 24 September 2011 16:41, Tom Lane wrote:
Frankly, with the tool in its current state I'd rather not run it at
all, ever. The value per man-hour expended is too low. The mess it
made out of the xlog-related includes this time around makes me
On 24 September 2011 16:41, Tom Lane wrote:
> Frankly, with the tool in its current state I'd rather not run it at
> all, ever. The value per man-hour expended is too low. The mess it
> made out of the xlog-related includes this time around makes me question
> whether it's even a net benefit, re
Bruce Momjian writes:
> Tom Lane wrote:
>> Actually, I believe that the *main* problem with pgrminclude is that
>> it fails to account for combinations of build options other than those
>> that Bruce uses. In the previous go-round, the reason we were still
>> squashing bugs months later is that i
Tom Lane wrote:
> Actually, I believe that the *main* problem with pgrminclude is that
> it fails to account for combinations of build options other than those
> that Bruce uses. In the previous go-round, the reason we were still
> squashing bugs months later is that it took that long for people t
Bruce Momjian writes:
> Robert Haas wrote:
>> I'm also curious to see how much more fallout we're going to see from
>> that run. We had a few glitches when it was first done, but it didn't
>> seem like they were really all that bad. It might be that we'd be
>> better off running pgrminclude a lo
Robert Haas wrote:
> On Fri, Sep 9, 2011 at 11:28 PM, Peter Geoghegan
> wrote:
> > It's very difficult or impossible to anticipate how effective the tool
> > will be in practice, but when you consider that it works and does not
> > produce false positives for the first 3 real-world cases tested,
On Wed, 2011-09-07 at 01:22 +0200, Jan Urbański wrote:
> On 07/09/11 01:13, Peter Geoghegan wrote:
> > On 6 September 2011 08:29, Peter Eisentraut wrote:
> >> I was thinking about splitting up plpython.c, but it's not even on that
> >> list. ;-)
> >
> > IIRC the obesity of that file is something
On 23 September 2011 15:46, Robert Haas wrote:
> I'm not opposed to adding something like this, but I think it needs to
> either be tied into the actual running of the script, or have a lot
> more documentation than it does now, or both. I am possibly stupid,
> but I can't understand from reading
On Fri, Sep 9, 2011 at 11:28 PM, Peter Geoghegan wrote:
> It's very difficult or impossible to anticipate how effective the tool
> will be in practice, but when you consider that it works and does not
> produce false positives for the first 3 real-world cases tested, it
> seems reasonable to assum
I've produced the refinement of my little shell script anticipated by
my last e-mail (using sed to remove irrelevant variations in
__func__.12345 type symbol names). I decided to test it for:
1. Detecting behavioural changes when removing existing "pgrminclude
ignore" files (Basically headers that
On Fri, Sep 9, 2011 at 6:57 AM, Heikki Linnakangas
wrote:
>> In particular, I'd like to know what
>> boundaries it is envisaged that the code should be refactored along to
>> increase its conceptual integrity, or to better separate concerns. I
>> assume that that's the idea, since each new .c file
On 08.09.2011 23:45, Peter Geoghegan wrote:
On 8 September 2011 15:43, Robert Haas wrote:
I wouldn't be too enthusiastic about
starting a project like this in January, but now seems fine. A bigger
problem is that I don't hear anyone volunteering to do the work.
You seem to have a fairly stro
On Thu, Sep 8, 2011 at 4:45 PM, Peter Geoghegan wrote:
> On 8 September 2011 15:43, Robert Haas wrote:
>> I wouldn't be too enthusiastic about
>> starting a project like this in January, but now seems fine. A bigger
>> problem is that I don't hear anyone volunteering to do the work.
>
> You seem
Simon, Robert, Bruce, Tom,
>>> Say what? When else would you have us do it?
>> >
>>> >> When else would you have us develop?
>> >
>> > In my eyes that sort of activity *is* development. I find the
>> > distinction you are drawing entirely artificial, and more calculated to
>> > make sure re
On 8 September 2011 15:43, Robert Haas wrote:
> I wouldn't be too enthusiastic about
> starting a project like this in January, but now seems fine. A bigger
> problem is that I don't hear anyone volunteering to do the work.
You seem to have a fairly strong opinion on the xlog.c code. It would
be
Simon Riggs writes:
> You clearly have the bit between your teeth on this.
Personally, I'm neither intending to break up xlog.c right now, nor
asking you to do it. I'm just objecting to your claim that there
should be some project-policy restriction on when refactoring gets done.
I do have other
Simon Riggs wrote:
> On Thu, Sep 8, 2011 at 3:25 PM, Tom Lane wrote:
> > Simon Riggs writes:
> >> On Wed, Sep 7, 2011 at 9:02 PM, Tom Lane wrote:
> >>> Simon Riggs writes:
> Please lets not waste effort on refactoring efforts in mid dev cycle.
> >
> >>> Say what? ?When else would you have
On Thu, Sep 8, 2011 at 3:25 PM, Tom Lane wrote:
> Simon Riggs writes:
>> On Wed, Sep 7, 2011 at 9:02 PM, Tom Lane wrote:
>>> Simon Riggs writes:
Please lets not waste effort on refactoring efforts in mid dev cycle.
>
>>> Say what? When else would you have us do it?
>
>> When else would yo
On Thu, Sep 8, 2011 at 10:29 AM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Simon Riggs writes:
>> > On Wed, Sep 7, 2011 at 9:02 PM, Tom Lane wrote:
>> >> Simon Riggs writes:
>> >>> Please lets not waste effort on refactoring efforts in mid dev cycle.
>>
>> >> Say what? When else would you have
Tom Lane wrote:
> Simon Riggs writes:
> > On Wed, Sep 7, 2011 at 9:02 PM, Tom Lane wrote:
> >> Simon Riggs writes:
> >>> Please lets not waste effort on refactoring efforts in mid dev cycle.
>
> >> Say what? ?When else would you have us do it?
>
> > When else would you have us develop?
>
> In
Simon Riggs writes:
> On Wed, Sep 7, 2011 at 9:02 PM, Tom Lane wrote:
>> Simon Riggs writes:
>>> Please lets not waste effort on refactoring efforts in mid dev cycle.
>> Say what? When else would you have us do it?
> When else would you have us develop?
In my eyes that sort of activity *is*
On Wed, Sep 7, 2011 at 9:02 PM, Tom Lane wrote:
> Simon Riggs writes:
>> Please lets not waste effort on refactoring efforts in mid dev cycle.
>
> Say what? When else would you have us do it?
When else would you have us develop?
Major changes happen at start of a dev cycle, after some discussi
Simon Riggs writes:
> Please lets not waste effort on refactoring efforts in mid dev cycle.
Say what? When else would you have us do it?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:/
On Wed, Sep 7, 2011 at 7:12 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> Robert Haas wrote:
>>> I was less concerned about the breakage that might be caused by
>>> variables acquiring unintended referents - which should be unlikely
>>> anyway given reasonable variable naming conventions - and m
Bruce Momjian writes:
> Robert Haas wrote:
>> I was less concerned about the breakage that might be caused by
>> variables acquiring unintended referents - which should be unlikely
>> anyway given reasonable variable naming conventions - and more
>> concerned that the associated refactoring would
Robert Haas wrote:
> > IMHO, when manipulating code at this sort of macro scale, it's good to
> > be paranoid and exhaustive, particularly when it doesn't cost you
> > anything anyway. Unlike when writing or fixing a bit of code at a
> > time, which we're all used to, if the compiler doesn't tell y
On Tue, Sep 6, 2011 at 9:14 PM, Peter Geoghegan wrote:
> On 7 September 2011 01:18, Bruce Momjian wrote:
>> I am confused how moving a function from one C file to another could
>> cause breakage?
>
> I'm really concerned about silent breakage, however unlikely - that is
> also Simon and Robert's
On 7 September 2011 01:18, Bruce Momjian wrote:
> I am confused how moving a function from one C file to another could
> cause breakage?
I'm really concerned about silent breakage, however unlikely - that is
also Simon and Robert's concern, and rightly so. If it's possible in
principle to guard a
Peter Geoghegan wrote:
> On 7 September 2011 00:13, Peter Geoghegan wrote:
> > * Within TUs, we unshadow a previously shadowed variable, so we link
> > to a global variable rather than one local to the original/other new
> > file. Unlikely to be a problem. Here's what I get when I compile
> > xlog
On 7 September 2011 00:13, Peter Geoghegan wrote:
> * Within TUs, we unshadow a previously shadowed variable, so we link
> to a global variable rather than one local to the original/other new
> file. Unlikely to be a problem. Here's what I get when I compile
> xlog.c in the usual way with the addi
On 07/09/11 01:13, Peter Geoghegan wrote:
> On 6 September 2011 08:29, Peter Eisentraut wrote:
>> I was thinking about splitting up plpython.c, but it's not even on that
>> list. ;-)
>
> IIRC the obesity of that file is something that Jan Urbański intends
> to fix, or is at least concerned about.
On 6 September 2011 21:07, Robert Haas wrote:
> On Tue, Sep 6, 2011 at 3:56 PM, Simon Riggs wrote:
>> The only way I would entertain thoughts of major refactoring would be
>> if comprehensive tests were contributed, so we could verify everything
>> still works afterwards.
>
> That sounds like a r
On Tue, Sep 6, 2011 at 3:56 PM, Simon Riggs wrote:
> The only way I would entertain thoughts of major refactoring would be
> if comprehensive tests were contributed, so we could verify everything
> still works afterwards.
That sounds like a really good idea. Mind you, I don't have a very
clear i
On Tue, Sep 6, 2011 at 3:05 PM, Bruce Momjian wrote:
> Peter Eisentraut wrote:
>> On l?r, 2011-09-03 at 19:18 -0400, Bruce Momjian wrote:
>> > FYI, here are all the C files with over 6k lines:
>> >
>> > - 45133 ./interfaces/ecpg/preproc/preproc.c
>> > - 33651 ./backend/parser/gram.c
>> > - 1755
Peter Eisentraut wrote:
> On l?r, 2011-09-03 at 19:18 -0400, Bruce Momjian wrote:
> > FYI, here are all the C files with over 6k lines:
> >
> > - 45133 ./interfaces/ecpg/preproc/preproc.c
> > - 33651 ./backend/parser/gram.c
> > - 17551 ./backend/parser/scan.c
> >14209 ./bin/pg_dump/pg_dump.
On lör, 2011-09-03 at 19:18 -0400, Bruce Momjian wrote:
> FYI, here are all the C files with over 6k lines:
>
> - 45133 ./interfaces/ecpg/preproc/preproc.c
> - 33651 ./backend/parser/gram.c
> - 17551 ./backend/parser/scan.c
>14209 ./bin/pg_dump/pg_dump.c
>10590 ./backend/access/transam/
On Mon, Sep 5, 2011 at 6:56 PM, Alvaro Herrera
wrote:
> Excerpts from Bruce Momjian's message of sáb sep 03 20:18:47 -0300 2011:
>> FYI, here are all the C files with over 6k lines:
>>
>> - 45133 ./interfaces/ecpg/preproc/preproc.c
>> - 33651 ./backend/parser/gram.c
>> - 17551 ./backend/parser/
Excerpts from Bruce Momjian's message of sáb sep 03 20:18:47 -0300 2011:
> FYI, here are all the C files with over 6k lines:
>
> - 45133 ./interfaces/ecpg/preproc/preproc.c
> - 33651 ./backend/parser/gram.c
> - 17551 ./backend/parser/scan.c
>14209 ./bin/pg_dump/pg_dump.c
>10590 ./backen
FYI, here are all the C files with over 6k lines:
- 45133 ./interfaces/ecpg/preproc/preproc.c
- 33651 ./backend/parser/gram.c
- 17551 ./backend/parser/scan.c
14209 ./bin/pg_dump/pg_dump.c
10590 ./backend/access/transam/xlog.c
9764 ./backend/commands/tablecmds.c
8681 ./backend/util
44 matches
Mail list logo
