Re: Let's get rid of the separate minor version numbers for shlibs

> 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