Re: Adding Node support in outfuncs.c and readfuncs.c - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Adding Node support in outfuncs.c and readfuncs.c
Date
Msg-id CABUevExekqCGfv7TrA3FssrDcShuGRv3JN7WauOT9jEp8e74hw@mail.gmail.com
Whole thread Raw
In response to Re: Adding Node support in outfuncs.c and readfuncs.c  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: Adding Node support in outfuncs.c and readfuncs.c  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
On Thu, Nov 17, 2011 at 09:50, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> What you've got here could be useful
>> to people who use emacs and understand they've got to hand-check the
>> results.  I'm not sure how much further it'd be useful to go.
>
> Agreed. That's the reason why I'm proposing src/tools/editors in the
> first place. I find that it's enough for most of the Nodes I've been
> dealing with recently (all the ones that initdb uses, for starters), and
> for the other ones it helps a lot in adding the to-be-hand-edited code
> at the right place in the right files.
>
> The goal for this tool is to be more useful an advice to Emacs users
> than the usual "pick another patch that added syntax in the past and try
> to reproduce what it did as far as nodes support functions goes".
>
> I can also maintain that in a separate git repository on github, but
> that only reduces the already very thin population that could find it
> useful.

Since people seem to be less than super-enthusiastic about putting
into the core distro, perhaps it would at least be a good
startingpoint to do this? Should we perhaps consider a "postgres
developer tools" common repository with just a random bunch of tools
that people come up with (I assume there are more than just one of
them sitting around peoples environments..)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Command Triggers
Next
From: Tom Lane
Date:
Subject: Re: Inlining comparators as a performance optimisation