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

There are a couple of things that need adjustment:

1. typo in the makefile - ((X) should be $(X)
2. these cases need to be fixed:

else if (strcmp(argv[i],"--includedir-server") ==0)
get_pkginclude_path(mypath,otherpath);
else if (strcmp(argv[i],"--libdir") == 0)
get_include_path(mypath,otherpath);

We might actually need one or two functions in port/path.c to handle them.

cheers

andrew

Bruce Momjian wrote:

Andrew Dunstan wrote:

There are a couple of things that need adjustment:

1. typo in the makefile - ((X) should be $(X)

OK.

2. these cases need to be fixed:

else if (strcmp(argv[i],"--includedir-server") ==0)
get_pkginclude_path(mypath,otherpath);
else if (strcmp(argv[i],"--libdir") == 0)
get_include_path(mypath,otherpath);

We might actually need one or two functions in port/path.c to handle them.

What is the problem here? Why do we need additional port/path
functions? I see libdir is mismatched with include_path.

-- 
  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

Bruce Momjian wrote:

Andrew Dunstan wrote:

2. these cases need to be fixed:

else if (strcmp(argv[i],"--includedir-server") ==0)
get_pkginclude_path(mypath,otherpath);
else if (strcmp(argv[i],"--libdir") == 0)
get_include_path(mypath,otherpath);

We might actually need one or two functions in port/path.c to handle them.

What is the problem here? Why do we need additional port/path
functions? I see libdir is mismatched with include_path.

I don't see a function there to report the libdir at all (only
pkglibdir), and for includedir-server we would need either to append
"/server" or to have a function in path.c that reported it for us correctly.

cheers

andrew

Andrew Dunstan wrote:

I don't see a function there to report the libdir at all (only
pkglibdir), and for includedir-server we would need either to append
"/server" or to have a function in path.c that reported it for us
correctly.

These paths can all be more or less independently (or at least
unpredictably) different, so you apparently need to treat each of them
individually.

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

Would someone address this and make a new patch? The files are in the
patch queue. Thanks.

---------------------------------------------------------------------------

Peter Eisentraut wrote:

Andrew Dunstan wrote:

I don't see a function there to report the libdir at all (only
pkglibdir), and for includedir-server we would need either to append
"/server" or to have a function in path.c that reported it for us
correctly.

These paths can all be more or less independently (or at least
unpredictably) different, so you apparently need to treat each of them
individually.

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

-- 
  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

Patch applied. Thanks.

I made all the changes you suggested and the additions to path.c for the
new parameters.

---------------------------------------------------------------------------

Andrew Dunstan wrote:

There are a couple of things that need adjustment:

1. typo in the makefile - ((X) should be $(X)
2. these cases need to be fixed:

else if (strcmp(argv[i],"--includedir-server") ==0)
get_pkginclude_path(mypath,otherpath);
else if (strcmp(argv[i],"--libdir") == 0)
get_include_path(mypath,otherpath);

We might actually need one or two functions in port/path.c to handle them.

cheers

andrew

Bruce Momjian wrote:

Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

-- 
  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

Bruce Momjian wrote:

Patch applied. Thanks.

I made all the changes you suggested and the additions to path.c for
the new parameters.

I think you forgot to commit the new source files.

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

Oops, sorry, done.

---------------------------------------------------------------------------

Peter Eisentraut wrote:

Bruce Momjian wrote:

Patch applied. Thanks.

I made all the changes you suggested and the additions to path.c for
the new parameters.

I think you forgot to commit the new source files.

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

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

-- 
  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

Bruce Momjian wrote:

Oops, sorry, done.

The --pgxs option seems to have gotten lost in the conversion.

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

Peter Eisentraut wrote:

Bruce Momjian wrote:

Oops, sorry, done.

The --pgxs option seems to have gotten lost in the conversion.

It wasn't there when I did the conversion. Usual problem of duelling
patches. Can you fix it, or do you need me to send in a patch?

cheers

andrew

OK, addition made, and I added documentation for -pgxs.

---------------------------------------------------------------------------

Andrew Dunstan wrote:

Peter Eisentraut wrote:

Bruce Momjian wrote:

Oops, sorry, done.

The --pgxs option seems to have gotten lost in the conversion.

It wasn't there when I did the conversion. Usual problem of duelling
patches. Can you fix it, or do you need me to send in a patch?

cheers

andrew

-- 
  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