Re: Adding Node support in outfuncs.c and readfuncs.c

Hi,

The task in $subject is something I will have to do repeatedly for
completing the Command Trigger patch. I've been doing some of them
manually, covering initdb. Then I've been scripting away the editing.

The script takes a Node number as input (because that's what you're
given in ERROR messages) and as an output will edit outfuncs.c and
readfuncs.c for you.

That's only intended as a developer friendly help, not a part of the
build process or the like, and I've been writing that in Emacs Lisp --
that's what make most sense to me (I don't do perl). Now, I intend to be
maintaining the script if needs be, and it could be useful for others
too.

What about adding that into src/tools/editors/pgsrc.el?

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> What about adding that into src/tools/editors/pgsrc.el?

Of course after having used it some more, I fixed a bug and added a
function to start from the readfunc node name rather than the enum node
number in the interactive calls.

Please find attached a newer version of the pgsrc.el file, in case it is
to get included. Also note that it's possible to just use those read
only commands:

M-x pgsrc:get-node-name RET 718 RET
Node 718 is T_DropStmt.

M-x pgsrc:get-node-number RET COLUMNDEF RET
Node COLUMNDEF is 917 in enum NodeTag.

Also, the code generated is not handling the more complex case, for
example I had to adapt of rewrite some nodes (the constraint reading is
not something easy to generate from a script). But even with such
limitations, I still find the tool helping a lot.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
>> What about adding that into src/tools/editors/pgsrc.el?

Should I add an item for that in the commit fest?

--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

On Tue, Nov 15, 2011 at 5:41 AM, Dimitri Fontaine
<dimitri(at)2ndquadrant(dot)fr> wrote:
> Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
>> Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
>>> What about adding that into src/tools/editors/pgsrc.el?
>
> Should I add an item for that in the commit fest?

Sounds like a good idea.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Should I add an item for that in the commit fest?
>
> Sounds like a good idea.

Done: https://commitfest.postgresql.org/action/patch_view?id=707

Note: I might also add support for equalfuncs and copyfuncs while at,
been doing that again and I guess I would just M-x it next time.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

On ons, 2011-11-09 at 20:14 +0100, Dimitri Fontaine wrote:
> The task in $subject is something I will have to do repeatedly for
> completing the Command Trigger patch. I've been doing some of them
> manually, covering initdb. Then I've been scripting away the editing.
>
> The script takes a Node number as input (because that's what you're
> given in ERROR messages) and as an output will edit outfuncs.c and
> readfuncs.c for you.
>
> That's only intended as a developer friendly help, not a part of the
> build process or the like, and I've been writing that in Emacs Lisp --
> that's what make most sense to me (I don't do perl). Now, I intend to
> be
> maintaining the script if needs be, and it could be useful for others
> too.
>
> What about adding that into src/tools/editors/pgsrc.el?

This is a massive amount of code that very few people in our community
will use, and very few be able to maintain it, too. If you want to make
a lasting contribution on this area, write a program that generates the
node handling functionality automatically as part of the build process.

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> This is a massive amount of code that very few people in our community
> will use, and very few be able to maintain it, too. If you want to make
> a lasting contribution on this area, write a program that generates the
> node handling functionality automatically as part of the build process.

Can emacs --batch be used there? If not, apart from C and perl, what
can I use?

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> This is a massive amount of code that very few people in our community
>> will use, and very few be able to maintain it, too.

It's not that "massive", at least not as it stands, although I agree it
looks distressingly write-only.

>> If you want to make
>> a lasting contribution on this area, write a program that generates the
>> node handling functionality automatically as part of the build process.

> Can emacs --batch be used there? If not, apart from C and perl, what
> can I use?

You can *not* assume that emacs is available in any random build
environment; and not C either, because it might be a cross-compile.
It'd have to be Perl.

FWIW, even though I use emacs exclusively, I have little or no interest
in this approach myself. I don't think the node functions are as
boilerplate as you think --- for one thing, how will you deal with
typedef'd field types? (Assuming any unknown type name is a node type
is not right.) And even ignoring that, there are always exceptions to
any general rule.

If Peter is seriously suggesting that construction of the backend/nodes
files could be automated entirely, I think he's nuts. The amount of
work to construct a bulletproof tool (if it's possible at all) would
greatly outweigh the benefit. 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.

regards, tom lane

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

On Thu, Nov 17, 2011 at 09:50, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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/

Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> 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..)

I'm now thinking this script will be happy being on its own on github.
There's already peg over there that targets developers, and
pgbench-tools too, by Greg.

And setting pgsrc.el as a separate repository will make it easier to
integrate into el-get (well, I've just done that, so if you already use
el-get, install pgsrc-el and you're done, if interested).

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support