> The only place where we'd have a problem is the ecpg preprocessor > itself, which is scheduled to be at version 4.13 this year. However, > that version number is purely cosmetic since AFAICS the only thing > that gets done with it is to print it in response to -v and suchlike. > I don't really see why ecpg has its own version number anyway --- > why don't we go over to giving it the same version number as the > rest of PG? So it would just print the PG_VERSION string in the > places > where it currently prints the numbers hard-wired in > ecpg/preproc/Makefile.
Absolutely agreed. The current numbering is historical but does not seem to make sense anymore. Besides, the main usage I see is that you can see which preprocessor version was used to create a certain C file. With the preprocessor's parser being auto-generated having the PG version makes much more sense IMO. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
