Re: Let's get rid of the separate minor version numbers for shlibs - Mailing list pgsql-hackers

From Michael Meskes
Subject Re: Let's get rid of the separate minor version numbers for shlibs
Date
Msg-id 1471332659.4410.67.camel@postgresql.org
Whole thread Raw
In response to Let's get rid of the separate minor version numbers for shlibs  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> 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



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Index Onlys Scan for expressions
Next
From: Haribabu Kommi
Date:
Subject: Re: System load consideration before spawning parallel workers