Обсуждение: Why does pg_ctl.c have its own copy of PM_VERSIONSTR?

Why isn't pg_ctl.c using PG_VERSIONSTR from miscadmin.h?  Seems like
this is something that will have to be kept in sync manually (I see
from the CVS logs that Peter already had to do that once).

If the feeling is that miscadmin.h is a backend include file that
shouldn't be used by pg_ctl (which is not totally unreasonable,
though I think there's no harm in it given the current contents
of that file), maybe we should move PG_VERSIONSTR someplace else?
        regards, tom lane

Tom Lane wrote:
> Why isn't pg_ctl.c using PG_VERSIONSTR from miscadmin.h?  Seems like
> this is something that will have to be kept in sync manually (I see
> from the CVS logs that Peter already had to do that once).
>
> If the feeling is that miscadmin.h is a backend include file that
> shouldn't be used by pg_ctl (which is not totally unreasonable,
> though I think there's no harm in it given the current contents
> of that file), maybe we should move PG_VERSIONSTR someplace else?
>
>
>   

Your opinion of my memory at nearly 4 years remove is way too high :-)

I don't even know if that was my doing or Bruce's - probably mine though.

It looks like I adapted it from initdb.c - that would make sense given 
the time frames.

There is unlikely to be any deep reason.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> Why isn't pg_ctl.c using PG_VERSIONSTR from miscadmin.h?

> It looks like I adapted it from initdb.c - that would make sense given 
> the time frames.

Oh, I hadn't seen the one in initdb.c.  That's just plain silly,
seeing that it's including miscadmin.h already.  (Which means that
non-backend inclusion of this file works already...)

> There is unlikely to be any deep reason.

OK, will fix.
        regards, tom lane