pg_config

Andrew Dunstan wrote:

I know it's not critical, but is it worth rewriting pg_config in C so it
works on Windows (or alternatively writing it as a .bat file for Windows)?

Oh, pg_config is a shell script. Yes, it should be rewritten in C.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Andrew Dunstan <andrew@dunslane.net> writes:

I know it's not critical, but is it worth rewriting pg_config in C so it
works on Windows (or alternatively writing it as a .bat file for Windows)?

I doubt it. People can always just read the file to see what settings
are in it, and it's not like nonexperts are going to have a variety of
different configurations that we're gonna have to ask them about.
(Even in the Unix world, pg_config is not really needed when most people
are installing one of a small number of RPM-type packages...)

regards, tom lane

Tom Lane wrote:

I doubt it. People can always just read the file to see what
settings are in it, and it's not like nonexperts are going to have a
variety of different configurations that we're gonna have to ask them
about. (Even in the Unix world, pg_config is not really needed when
most people are installing one of a small number of RPM-type
packages...)

The point of pg_config is not primarily to debug the installation layout
for us. pg_config is used in configure scripts to find PostgreSQL
libraries and header files. I don't know if Windows users have a
similar need.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut said:

Tom Lane wrote:

I doubt it. People can always just read the file to see what
settings are in it, and it's not like nonexperts are going to have a
variety of different configurations that we're gonna have to ask them
about. (Even in the Unix world, pg_config is not really needed when
most people are installing one of a small number of RPM-type
packages...)

ISTM that if it's not useful we should rip it out and if it is then we
should make it portable.

The point of pg_config is not primarily to debug the installation
layout for us. pg_config is used in configure scripts to find
PostgreSQL libraries and header files.

To that extent is it not broken by relocated installations that we have now
made some provision for?

I don't know if Windows users
have a similar need.

I don't see why not.

cheers

andrew

Andrew Dunstan wrote:

Peter Eisentraut said:

Tom Lane wrote:

I doubt it. People can always just read the file to see what
settings are in it, and it's not like nonexperts are going to have a
variety of different configurations that we're gonna have to ask them
about. (Even in the Unix world, pg_config is not really needed when
most people are installing one of a small number of RPM-type
packages...)

ISTM that if it's not useful we should rip it out and if it is then we
should make it portable.

Agreed. Right now we have a shell script in the Win32 binary directory
that doesn't work for them.

The point of pg_config is not primarily to debug the installation
layout for us. pg_config is used in configure scripts to find
PostgreSQL libraries and header files.

To that extent is it not broken by relocated installations that we have now
made some provision for?

Good question.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Andrew Dunstan wrote:

To that extent is it not broken by relocated installations that we
have now made some provision for?

Well, then it should be fixed to take relocated installations into
account.

Relocatable installations are by nature a pretty broken feature. When
you use pg_config to locate, say, libpq, then compile your third-party
package, and then move libpq somewhere else, nothing can save you
(except moving libpq back). At least on Unix, relocatable
installations are a walking cane when you need parallel installations
for upgrades, but they'll never work reliably in general.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:

Andrew Dunstan wrote:

To that extent is it not broken by relocated installations that we
have now made some provision for?

Well, then it should be fixed to take relocated installations into
account.

Relocatable installations are by nature a pretty broken feature. When
you use pg_config to locate, say, libpq, then compile your third-party
package, and then move libpq somewhere else, nothing can save you
(except moving libpq back). At least on Unix, relocatable
installations are a walking cane when you need parallel installations
for upgrades, but they'll never work reliably in general.

Of course, if you rely on pg_config and then move the installation you
will put a very large hole in your foot. But we can't make things
totally idiot-proof - they will just build a better idiot.

Here is an attempt to do the Right Thing (tm) in C.

cheers

andrew