Re: Adding Node support in outfuncs.c and readfuncs.c
От | Tom Lane |
---|---|
Тема | Re: Adding Node support in outfuncs.c and readfuncs.c |
Дата | |
Msg-id | 24907.1321489790@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Adding Node support in outfuncs.c and readfuncs.c (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
Ответы |
Re: Adding Node support in outfuncs.c and readfuncs.c
|
Список | pgsql-hackers |
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes: > Peter Eisentraut <peter_e@gmx.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
В списке pgsql-hackers по дате отправления: