feature request: show pgsql version when running initdb

Christopher Kings-Lynne writes:

Is there any chance we could have initdb show the version of postgresql
it is running as when initdb is run?

If you install many different versions in parallel, don't you give your
installation paths some meaning that contain the version number? In any
case, you can run initdb --version first if you're not sure about what is
where.

--
Peter Eisentraut peter_e@gmx.net

Is there any chance we could have initdb show the version of postgresql
it is running as when initdb is run?

If you install many different versions in parallel, don't you give your
installation paths some meaning that contain the version number? In any
case, you can run initdb --version first if you're not sure about what is
where.

Yes I do, but sometimes as different users you don't know what the path
is. I guess I can just go --version.

Chris

On Fri, 26 Sep 2003 04:51 pm, Christopher Kings-Lynne wrote:

Yes I do, but sometimes as different users you don't know what the path
is. I guess I can just go --version.

Perhaps add
alias initdb='initdb --version; initdb'
to /etc/profile so that all accounts get an alias?

Regards, Philip Yarra.

On Fri, 26 Sep 2003, Christopher Kings-Lynne wrote:

If you install many different versions in parallel, don't you give your
installation paths some meaning that contain the version number? In any
case, you can run initdb --version first if you're not sure about what is
where.

Yes I do, but sometimes as different users you don't know what the path
is. I guess I can just go --version.

Or just:
which initdb
which is a bit easier to interpret than:
echo $path
which is what you really want to know, i.e. what are the default paths applied
in the search for an executable invoked without an explicit path.

I think the problem here is the assumption that you don't need to explicitly
state the path to the executable when invoking a command from multiple
installations. If you've got specific requirements on which version to run
never just assume which one will be picked up, always take steps to verify
which one it is, explicitly state which one to use or accept that you may well
end up running the wrong and have to start again (if you're lucky enough to be
trying something that isn't going to permanently move you into a state where
you can't start again).

To take the normal sort of example in reverse:

I have a script for reading manuals, I call it rm, it can take some switches
lets say r and f, as well as the name of something to read about. I happen to
be sitting in / and I look and start wondering why there's a /sbin. So I think
I'll see if there's anything in the document store about it. So I type:
rm -rf sbin
(to do a recursive search of formated documents perhaps). I don't think about
it, verify it or anything. Why should I? It always just works. Unfortunately,
although I do know I'm doing this as root it doesn't occur to me there might be
another command called rm installed somewhere on the system that I might pick
up instead.

Moral of the story, if it's in your path first then it's the default and you
should therefore be happy with the results or be prepared to live with them,
otherwise make sure what you're running.

--
Nigel J. Andrews

On Fri, 26 Sep 2003, Christopher Kings-Lynne wrote:

Is there any chance we could have initdb show the version of postgresql
it is running as when initdb is run?

If you install many different versions in parallel, don't you give your
installation paths some meaning that contain the version number? In any
case, you can run initdb --version first if you're not sure about what is
where.

Yes I do, but sometimes as different users you don't know what the path
is. I guess I can just go --version.

Anytime I'm running multple versions on the same box, I install them to
paths like /usr/local/pgsql72 and create a user like pgsql72 and then set
it so the path for that use is /usr/local/pgsql72/bin.

that way, just looking at the command prompt I know which version /
superuser I'm playing with. Plus, no matter how badly I try to screw up,
pgsql72 doen't have permission to initdb pgsql73's $PGDATA directory.

"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:

Moral of the story, if it's in your path first then it's the default and you
should therefore be happy with the results or be prepared to live with them,
otherwise make sure what you're running.

I would think that having initdb print its version while running would
be in the category of "too late to help" anyway. Making a habit of
running "initdb --version" in advance seems like much the better way
to proceed, if this is a problem for you.

Personally I've never had such a mistake occur, even though I normally
have several different PG installations active on my development
machines. I think this is because I always set PATH, PGPORT, and PGDATA
consistently --- rather than manipulating them by hand, I have little
scripts that I run to make one installation or another the "active" one.

regards, tom lane

Tom Lane wrote:

"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:

Moral of the story, if it's in your path first then it's the default and you
should therefore be happy with the results or be prepared to live with them,
otherwise make sure what you're running.

I would think that having initdb print its version while running would
be in the category of "too late to help" anyway. Making a habit of
running "initdb --version" in advance seems like much the better way
to proceed, if this is a problem for you.

Personally I've never had such a mistake occur, even though I normally
have several different PG installations active on my development
machines. I think this is because I always set PATH, PGPORT, and PGDATA
consistently --- rather than manipulating them by hand, I have little
scripts that I run to make one installation or another the "active" one.

It might make sense to have the version explicitly reported by
show_setting/debug modes - the change would be entirely trivial and not
very intrusive to general use.

cheers

andrew